Repository navigation
[benchmark] Request for call-path / fairness review (GLD.SerializerBenchmark) #252
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: csharp, harness name: NetJSON).
Implementation we use:
https://github.com/leo-gan/GLD.SerializerBenchmark/blob/master/c-sharp/src/Serializers/NetJSONSer.cs
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 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
Activity
rpgmaker commentedon Jul 18, 2026
Hi, thanks for seeking my input on this topic. I will review it later today and provide answers to the questions you requested above.
Thanks
rpgmaker commentedon Jul 20, 2026
In looking at the serialization logic, i will expect it to use generic instead of "object" since internally, that will cause it to do normal dynamic reflection which is very slow. The deserialization is fine somewhat since the type is been provided. But would suggest having a base class for SerDeser instead to avoid the boxing and unboxing issues been factored into the overall benchmark; not just for netjson but for all serializers. if it is not possible, then i will suggest passing the Type object the serialize method itself to avoid anything that will trigger the wrong code path.
To make the benchmark more effective for validation and etc; i would suggest seperating the writing to StreamWriter and reading of StreamReader into the logic since this will reflect different performance after some numbers of runs such as whether the GC is interrupting or not during the runs.
I will propose something like this
Also which .net version are you running most of this benchmarks on?