3 ms·

> The relevance is that even a 175 LOC project in Java takes up enormous memory and disk footprint _This particular_ 175 LOC Java project takes up an enormous

by xienze 11y ago

> The relevance is that even a 175 LOC project in Java takes up enormous memory and disk footprint _This particular_ 175 LOC Java project takes up an enormous amount of memory. For all you know it was just coded poorly and the Go one is a bit more reasonable. > the JVM is this super-heavyweight thing that's really just inherently inappropriate for a lot of applications. The JVM introduces overhead but not so much that you can make these sorts of extrapolations.

mkozlows 11y ago
34MB for Hello World, according to this SO post: http://stackoverflow.com/questions/13692206/high-java-memory-usage-even-for-small-programs http://stackoverflow.com/questions/13692206/high-java-memory... I'm not going to install the JDK just to verify, but feel free to report back if you get different results.
- tracker1 11y ago
  For comparison... I did a similar Hello World test around the timeframe of .Net 2.0, and it was around 11mb to load IIRC. The latest iojs on windows seems to be just under 9mb. Not sure what the golang overhead is, by comparison.
  - icebraining 11y ago
    I can't say what an Hello World uses, but I have a Tumblr API → RSS gateway written in Go running for a few months, and it uses ~2MB.
vonsnowman 11y ago
The footprint of this particular service could have been optimized in Java but: 1. the JVM itself imposes a high floor (hotspot, many shared libs loaded, ...) 2. the Java language is full of overhead at every level (boxed types are a pet peeve of mine) 3. the Java ecosystem has a tendency to regard memory as an inexhaustible resource, which lead a lot of waste in many 3rd party libraries The core point is that optimizing this particular Java program (and the others that followed) would have been more time-consuming than a Golang rewrite and would have probably increased the complexity whereas a Golang rewrite reduced it. Optimization was the original goal, increased maintainability was a pleasant result.
- vardump 11y ago
  Point 2... yeah, that's one of my major problems with Java. Unnecessary boxing and the unreasonable amount of complexity if you work around it. In any type of Object collections, it consumes memory, stresses garbage collector unnecessarily and causes a lot of CPU cache misses. Value types would help so much with this issue. I know they're coming one day. I hope Java/JVM can replicate memory efficiency and cache coherence of C++ std::vector for small objects.

by xienze 11y ago

mkozlows 11y ago

34MB for Hello World, according to this SO post: http://stackoverflow.com/questions/13692206/high-java-memory-usage-even-for-small-programs http://stackoverflow.com/questions/13692206/high-java-memory... I'm not going to install the JDK just to verify, but feel free to report back if you get different results.

tracker1 11y ago
For comparison... I did a similar Hello World test around the timeframe of .Net 2.0, and it was around 11mb to load IIRC. The latest iojs on windows seems to be just under 9mb. Not sure what the golang overhead is, by comparison.
- icebraining 11y ago
  I can't say what an Hello World uses, but I have a Tumblr API → RSS gateway written in Go running for a few months, and it uses ~2MB.

vonsnowman 11y ago

The footprint of this particular service could have been optimized in Java but: 1. the JVM itself imposes a high floor (hotspot, many shared libs loaded, ...) 2. the Java language is full of overhead at every level (boxed types are a pet peeve of mine) 3. the Java ecosystem has a tendency to regard memory as an inexhaustible resource, which lead a lot of waste in many 3rd party libraries The core point is that optimizing this particular Java program (and the others that followed) would have been more time-consuming than a Golang rewrite and would have probably increased the complexity whereas a Golang rewrite reduced it. Optimization was the original goal, increased maintainability was a pleasant result.

vardump 11y ago
Point 2... yeah, that's one of my major problems with Java. Unnecessary boxing and the unreasonable amount of complexity if you work around it. In any type of Object collections, it consumes memory, stresses garbage collector unnecessarily and causes a lot of CPU cache misses. Value types would help so much with this issue. I know they're coming one day. I hope Java/JVM can replicate memory efficiency and cache coherence of C++ std::vector for small objects.