protocolbuffers / protocolbuffers/protobuf

[benchmark] Request for call-path / fairness review (GLD.SerializerBenchmark)

Open
#29,581 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
72k
Forks
16.3k
Avg merge
1d 17h
Merged PRs (30d)
140

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: php, harness name: protobuf).
Implementation we use:

https://github.com/leo-gan/GLD.SerializerBenchmark/blob/master/php/src/Serializers/ProtobufSer.php

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing php/src/Serializers/ProtobufSer.php in the linked GLD.SerializerBenchmark repository, then compare its call pattern with the recommended performance-sensitive use of this library. Determine whether options, encoder or decoder reuse, types, or buffer handling affect fairness. Done means providing concrete review notes or a small wrapper PR, with any relevant documentation corrections identified.

Written by the indexing model from the issue text.

Assessment

Tech stack
php
Domain
performance, testing-qa
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.