6 ms·

Watch as I don't use protobuf because it is horrible. .... Tada! If you patch clients to google services in Python to use json instead of grpc they get faste

Watch as I don't use protobuf because it is horrible. .... Tada! If you patch clients to google services in Python to use json instead of grpc they get faster and more reliable. A lot faster. Benchmark it! def get_json_client() -> CloudLoggingQueryClient: """Client for log queries (JSON transport, avoids gRPC overhead).""" client = google.cloud.logging.Client.from_service_account_info(...) client._use_grpc = False return client For me that is how I know something like protobuf is good. It is a nuisance to manage and distribute the definitions, adds a build step even to languages with no build step normally, is slower than almost every alternative, and artificially restricts you from doing lots of common things. It's so good! And look at the code quality of the implementation! It's like a team of interns wrote it while drunk. It is a complete spaghetti mess, but has tons of super convoluted micro optimizations that are slower than just doing the most obvious thing, but make the implementation confusing and indirect. It's trash code.

itsthecourier 2mo ago
so how do you save data over the cable when it's needed?
- ltbarcly3 2mo ago
  zstd?? Obviously?
- anematode 2mo ago
  JSON. /s
- throw1234567891 2mo ago
  Eventually it’s all bytes. Where do you want to save them?
pastel8739 2mo ago
Is this because load is lighter on their JSON endpoints that their gRPC ones?
- ltbarcly3 2mo ago
  [flagged]
tomtom1337 2mo ago
What are good alternatives when you need a common "single source of truth" schema shared between multiple languages? We use protobuf between c# and Python.
- ltbarcly3 2mo ago
  The goal is not to have a single source of truth schema. That is a means to some other goal, and it's not even a good means. If you never change the schema then you don't have to worry about it, get things working and never look back. If you do change your schema from time to time, you need testing between the two systems. If you have good tests again a single source of truth is fully redundant, both systems are talking just fine. If you don't have tests things can and will break all the time even using protobuf.
  - afavour 2mo ago
    > The goal is not to have a single source of truth schema. That is a means to some other goal, and it's not even a good means. It’s about data transmission. Being able to encode and decode in a type safe manner between different languages (and so, different platforms) is a goal that makes a lot of sense. > If you do change your schema from time to time, you need testing between the two systems Or you could just use a defined format that doesn’t require testing. I rarely use protobuf but I can see why people do. The guaranteed backwards compatibility is huge for people who can’t just publish a new web frontend at the drop of a hat.
    - ltbarcly3 2mo ago
      afavour it's been a long day already, maybe I can explain why you still need tests another day.
      - afavour 2mo ago
        You could always try being less condescending when replying to users and you might find there was no need for anyone to reply in the first place.
onei 2mo ago
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-...

itsthecourier 2mo ago

so how do you save data over the cable when it's needed?

ltbarcly3 2mo ago
zstd?? Obviously?
anematode 2mo ago
JSON. /s
throw1234567891 2mo ago
Eventually it’s all bytes. Where do you want to save them?

pastel8739 2mo ago

Is this because load is lighter on their JSON endpoints that their gRPC ones?

ltbarcly3 2mo ago
[flagged]

tomtom1337 2mo ago

What are good alternatives when you need a common "single source of truth" schema shared between multiple languages? We use protobuf between c# and Python.

ltbarcly3 2mo ago
The goal is not to have a single source of truth schema. That is a means to some other goal, and it's not even a good means. If you never change the schema then you don't have to worry about it, get things working and never look back. If you do change your schema from time to time, you need testing between the two systems. If you have good tests again a single source of truth is fully redundant, both systems are talking just fine. If you don't have tests things can and will break all the time even using protobuf.
- afavour 2mo ago
  > The goal is not to have a single source of truth schema. That is a means to some other goal, and it's not even a good means. It’s about data transmission. Being able to encode and decode in a type safe manner between different languages (and so, different platforms) is a goal that makes a lot of sense. > If you do change your schema from time to time, you need testing between the two systems Or you could just use a defined format that doesn’t require testing. I rarely use protobuf but I can see why people do. The guaranteed backwards compatibility is huge for people who can’t just publish a new web frontend at the drop of a hat.
  - ltbarcly3 2mo ago
    afavour it's been a long day already, maybe I can explain why you still need tests another day.
    - afavour 2mo ago
      You could always try being less condescending when replying to users and you might find there was no need for anyone to reply in the first place.

onei 2mo ago

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-...