[benchmark] Request for call-path / fairness review (GLD.SerializerBenchmark)
- Dominant language
- Java
- Stars
- 4.4k
- Forks
- 613
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 6
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 suite (language: java, harness name: `fastjson2`).
Implementation we use:
https://github.com/leo-gan/GLD.SerializerBenchmark/blob/master/java/src/main/java/benchmark/serializers/Fastjson2Ser.java
We would value a short review of whether our measurement is fair and idiomatic:
1. Does our call pattern match how you recommend using the library in performance-sensitive code?
2. Should we change options, encoder/decoder reuse, types, or buffer handling?
3. 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 a short Serialization course (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 by reviewing the external benchmark wrapper at java/src/main/java/benchmark/serializers/Fastjson2Ser.java and compare its call pattern with fastjson2's documented performance-sensitive usage. The work is done when concrete fairness feedback is documented, with any needed wrapper changes proposed or submitted as a small PR.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100