4 ms·

Is that a recent-ish improvement? I feel like HTTP/2 would be roughly the same performance for JSON and protobuf, so maybe this is HTTP/2 vs HTTP/3?

• ltbarcly3 2mo ago
  I think the overhead is protobuf itself but I can't check.
  • okanat 2mo ago
    Protobuf simply encode things way more efficient that JSON can define a single object. You're quite frankly spewing bullshit in this whole thread.
    • throw1234567891 2mo ago
      You don’t get what they say. It’s not about about how efficient it is after encode, it’s about how fast encode is. They are not spewing bs, they’re focusing on a single point. The question is: do you send it over the wite more often than performing encode/decode.
      • blanched 2mo ago
        That's what the person you replied to is talking about, and they're right. Putting aside the final byte size (where protobuf also wins), protobuf is faster at both encoding and decoding than json. There are numerous benchmarks you can find that show this. The advantages of json are not related to performance.
        • someothherguyy 2mo ago
          doesn't seem universally true, https://github.com/protobufjs/protobuf.js/issues/2114#issue-3678242372 https://github.com/protobufjs/protobuf.js/issues/2114#issue-...
          • esrauch 2mo ago
            If you're writing JS you cannot beat JSON.parse, because you're running the most optimized C++ implementation of JSON which will outcompete any decoder written JS itself. Which is not a very generalizable situation.
            • ltbarcly3 2mo ago
              Ok but that's the point. You are just explaining why the 'protobuf is faster' claim is generally false.
              • okanat 2mo ago
                It is generally correct. When both implementations are completely in the same language Protobuf will win. Instead of a pure-JS implementation one can also make a FFI module for Protobuf. The comparison that's being made is equivalent to implementing quick sort in Python and bubble sort in C++ and then declaring bubble sort is the better alternative. Anyone with a healthy understading of computer science and programming experience will not make bullshit claims like that.
                • ltbarcly3 2mo ago
                  You say 'generally correct', but then to make it correct you have to make a bunch of specific constraints. That's not general. I'm comparing the FFI using library in python to the json library in python, and json is faster for me. I showed how in the post. You are welcome to find my mistake.
                  • esrauch 2mo ago
                    I was the grandparent reply and I meant to only carve out "you cannot write anything in JavaScript faster than anything written in tuned C, and json.parse is the latter". Which link were you comparing FFI in python to json in python? The link I see seems to be about pure JavaScript language Protobuf impls vs json.parse?
        • ltbarcly3 2mo ago
          No, protobuf is not faster, not on Python, because google's implementation is poor. Python is the #1 language in the world right now. Don't use protobuf.
          • frumplestlatz 2mo ago
            That's not the lesson I'm taking away from this. Imagine how much faster the code would be if you didn't use Python.
  • pjjpo 2mo ago
    Comparing a wrapped C++ gRPC backed stack with an httpx/requests backed one is like comparing apples to elephants.