4 ms·
The Java gRPC SDK is heavily optimized by Google, much more than the Go one. Until recently Java pauses were a real issue, I worked with a lot of Java based so
by Thaxll 5y ago
The Java gRPC SDK is heavily optimized by Google, much more than the Go one. Until recently Java pauses were a real issue,
I worked with a lot of Java based solutions ( elastic search, hadoop etc ... ) and was never impressed by the GC.
- jeffbee 5y agoMaybe, but it's still not possible that the Java test has a median latency of 150µs, a tail latency of 350µs, and a regular need to stop the world for hundreds of milliseconds. That statement is simply not compatible with reality.
- Thaxll 5y agoAs I said the Java SDK is heavily optimized to do the least minimum of allocations. I mean if you don't allocate much the GC is not really an issue.
- jeffbee 5y agoOK but again, that is a statement totally contrary to the article. The article is claiming two things: that it is easier in Go to avoid the heap while Java is utterly dependent on allocating everything on the heap - which is not consistent with the experience of actual Java and Go programmers - and that Java has a "preference for high throughput and high latency" which it doesn't.
- Yoric 5y agoFWIW, I used to write some high-performance JavaScript. One of the tricks of the trade was to allocate early and make sure you avoid allocating once the loading phase has started, hence avoiding triggering the garbage-collector (in most runtimes/languages, gc phases are typically triggered by the allocator). This involved writing very non-idiomatic code, to a large extent reimplementing a form of high-level custom allocator on top of the existing allocator/gc, but it worked. I'd be very surprised if the same wasn't possible in Java. I don't know if this is how gRPC is written but it could explain an apparent contradiction.
- kaba0 5y agoWhile I agree that the java gRPC lib is better maintained, I don’t agree with your second point. Java’s GCs are the state of the art, that can manage heap sizes up to 16 terabytes. Other GC implementations would simply die there.
- throwaway894345 5y agoThat’s neat, but a lot of applications will never need 16TB.
- kaba0 5y agoThey are a beast in throughput as well (as well as alternatively, really really good at low-latency with the new GCs made specifically for that): https://news.ycombinator.com/item?id=29323468 https://news.ycombinator.com/item?id=29323468
- koffiezet 5y agoWell, you are talking about java applications...