Request for the fairness review
- Dominant language
- C++
- Stars
- 26.5k
- Forks
- 3.7k
- PR merge metrics
- No merged PRs in 30d
Description
Hello,
I'm Leonid Ganeline. We maintain an open multi-language serializer benchmark:
https://github.com/leo-gan/GLD.SerializerBenchmark
Your library is included in the benchmark (language: swift, harness name: `FlatBuffers`).
Implementation we use:
https://github.com/leo-gan/GLD.SerializerBenchmark/blob/master/swift/Sources/SerializerBenchmarkCore/Serializers/FlatBuffersSer.swift
We would value a short review of whether our measurement is fair and idiomatic:
- Does our call pattern match how you recommend using the library in performance-sensitive code?
- Should we change options, encoder/decoder reuse, types, or buffer handling?
- Is there a better API (or a second entry point worth a separate row in the suite)?
Concrete notes or a small PR against that wrapper would help a lot. We are happy to credit you in the docs.
The repo also includes short Serialization courses (101–401). If something important about your design is easy to misstate, a pointer is welcome—we can update the docs ourselves.
Thank you for maintaining this library.
Best regards,
Leonid Ganeline
Contributor guide
Research direction
Start with swift/Sources/SerializerBenchmarkCore/Serializers/FlatBuffersSer.swift in the linked benchmark and review its FlatBuffers call pattern. Compare the options, reuse, types, and buffer handling with the library's recommended Swift usage; done means concrete fairness guidance or a focused wrapper PR, plus any documentation corrections.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, swift
- Domain
- performance, testing-qa, tooling
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 42/100