51–60 of 78 posts
Earlier quoted context omitted.
> our entire service requires e2e latency under 20ms Why are you using Go then?
20ms is a pretty considerable amount of time WRT E2E transaction time in today's world. Can you expand on your concerns with Go?
EDIT: Fixed unfortunate typo
Earlier quoted context omitted.
> I _think_ allocating a slice of contiguous bytes and using unsafe pointers should work fine as long as you are very cautious about structs/vars with pointers into the buffer getting freed by the GC Go's GC is conservative, so I don't think you need to take any special caution in that regard. I would expect that you just need to take care that your casts are correct (e.g., that you aren't casting overlapping regions…
Go went to a precise GC with version 1.3
I wonder what Google is thinking about the v2 performance. It's well known that protobuf processing is taxing heavy on their data center [1]. It's hard to imagine they just leave it slow. Or do they? [1] https://research.google/pubs/pub44271/
Disclaimer: Google had a lot of internal stuff they considered important to their core tech competencies. For example, no open source about Google paxos APIs and infrastructure, networking, etc.
Earlier quoted context omitted.
20ms is a pretty considerable amount of time WRT E2E transaction time in today's world. Can you expand on your concerns with Go?
It's not really suitable for latency-critical applications. EDIT: Fixed unfortunate typo
Maybe I'm missing something, but my read of golang/protobuf#364[1] was that part of the motivation for the re-organization in protobuf-go v2 was to allow for optimizations like gogoprotobuf to be developed without requiring a complete fork. I totally understand that the authors of gogoprotobuf do not have the time to re-architect their library to use these hooks, but best I can figure this generator does not use thes…
Earlier quoted context omitted.
It's not really suitable for latency-critical applications. EDIT: Fixed unfortunate typo
was the double-negative intentional? I've used Go for sub-millisecond needs. So 20ms seems like it would be a reasonable choice from where I'm sitting.
Go doesn't give you control over inline vs indirect allocation, instead relying on escape analysis, which is notoriously finicky. Seemingly unrelated changes, along with compiler upgrades, can ruin your carefully optimized code.
This is especially heinous because it uses a GC; unnecessary allocations have a disproportionately large impact on your application performance. One or the other wouldn't be nearly as bad.
Time and time again we see reports from organizations/projects with perfectly fine average latency, but horrendous p95+ times, when written in Go - some going as far as to do straight-up insane optimizations (see Dragph) or rewrite in other languages.
Earlier quoted context omitted.
20ms is a pretty considerable amount of time WRT E2E transaction time in today's world. Can you expand on your concerns with Go?
It's not really suitable for latency-critical applications. EDIT: Fixed unfortunate typo
Maybe I'm missing something, but my read of golang/protobuf#364[1] was that part of the motivation for the re-organization in protobuf-go v2 was to allow for optimizations like gogoprotobuf to be developed without requiring a complete fork. I totally understand that the authors of gogoprotobuf do not have the time to re-architect their library to use these hooks, but best I can figure this generator does not use thes…
I haven't looked in more detail, but one blocker is that `ProtoMethods() *methods` returns a private type, making it effectively unimplementable outside this package.
Earlier quoted context omitted.
Until the GC kicks in and steals a full 200usec + a bunch of your throughput... (Holy shit, who is downvoting this? It's literally the whole article!)
If your path is sensitive to 200us of latency you should probably optimize your application and tune your GC. Typically 200us for freeing all unreachable memory is not a big deal.
okay, you've done this, three years later and it's the same thing again since you need to accomodate the new features. your users haven't upgraded their computers. what do you do ?
Earlier quoted context omitted.
I haven't looked in more detail, but one blocker is that `ProtoMethods() *methods` returns a private type, making it effectively unimplementable outside this package.
So, I thought this at one point, too. But it turns out that methods is a type alias to an unnamed type, so there's no package level privacy issues: https://github.com/protocolbuffers/protobuf-go/blob/v1.26.0/...