4 ms·

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!)

harikb 5y ago
Properly written Go code (or even Java for that matter) will try to minimize allocations. For Java, unless I am mistaken pause-less GC is only offered by Azul - $$
- morelisp 5y ago
  Yeah, the whole point of the article is that gRPC v2 (and frankly v1 for that matter) are not “properly written” to do this.
- RhodesianHunter 5y ago
  >or even Java Just in case you may be unaware, the latest GCs for Java (Shenandoah, ZGC) are miles ahead of anything available for Go due to sheer age and manpower. Parallel and Pauseless are easily achievable in most cases.
  - morelisp 5y ago
    Java's GC is better but Go's GC is also parallel and "pauseless" - iirc ZGC is 50-500usec which is comparable to Go's target 200usec. The point is, neither is "five orders of magnitude" below 20ms. And neither needs zero CPU even if it doesn't block other threads.
  - geodel 5y ago
    > Latest GCs for Java (Shenandoah, ZGC) are miles ahead of anything available. Beyond hyperbole, do you have any actual comparison of Go vs Java GC performance?
throwaway894345 5y ago
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.
- jcelerier 5y ago
  > If your path is sensitive to 200us of latency you should probably optimize your application and tune your GC. 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 ?
  - pjmlp 5y ago
    Run a profiler and optimize again.
    - jcelerier 5y ago
      Your original code is already optimized as much as is possible outside of the things mentioned by OP
      - pjmlp 5y ago
        Don't guess, measure. Then just like C, writing a tiny set of functions in Assembly is always an option.
        jcelerier 5y ago
        Keep in mind that I am referring to this: > If your path is sensitive to 200us of latency you should probably optimize your application and tune your GC. > Don't guess, measure. yes, I am saying that the original code has already gone through a complete optimization process, everything is written in written in assembly, and you are at 970us on your 1ms time budget. (I'm not pulling those out of thin air, I was literally at a client yesterday with some real-time code with a 1ms deadline on a desktop OS and we have to cram as much things as possible in that millisecond)

harikb 5y ago

Properly written Go code (or even Java for that matter) will try to minimize allocations. For Java, unless I am mistaken pause-less GC is only offered by Azul - $$

morelisp 5y ago
Yeah, the whole point of the article is that gRPC v2 (and frankly v1 for that matter) are not “properly written” to do this.
RhodesianHunter 5y ago
>or even Java Just in case you may be unaware, the latest GCs for Java (Shenandoah, ZGC) are miles ahead of anything available for Go due to sheer age and manpower. Parallel and Pauseless are easily achievable in most cases.
- morelisp 5y ago
  Java's GC is better but Go's GC is also parallel and "pauseless" - iirc ZGC is 50-500usec which is comparable to Go's target 200usec. The point is, neither is "five orders of magnitude" below 20ms. And neither needs zero CPU even if it doesn't block other threads.
- geodel 5y ago
  > Latest GCs for Java (Shenandoah, ZGC) are miles ahead of anything available. Beyond hyperbole, do you have any actual comparison of Go vs Java GC performance?

throwaway894345 5y ago

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.

jcelerier 5y ago
> If your path is sensitive to 200us of latency you should probably optimize your application and tune your GC. 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 ?
- pjmlp 5y ago
  Run a profiler and optimize again.
  - jcelerier 5y ago
    Your original code is already optimized as much as is possible outside of the things mentioned by OP
    - pjmlp 5y ago
      Don't guess, measure. Then just like C, writing a tiny set of functions in Assembly is always an option.
      - jcelerier 5y ago
        Keep in mind that I am referring to this: > If your path is sensitive to 200us of latency you should probably optimize your application and tune your GC. > Don't guess, measure. yes, I am saying that the original code has already gone through a complete optimization process, everything is written in written in assembly, and you are at 970us on your 1ms time budget. (I'm not pulling those out of thin air, I was literally at a client yesterday with some real-time code with a 1ms deadline on a desktop OS and we have to cram as much things as possible in that millisecond)