6 ms·

"Code size was reduced by almost half, from 175 lines down to 96." Hm, I how can we take a 175 LOC project as something relevant in any way?

mkozlows 11y ago
The relevance is that even a 175 LOC project in Java takes up enormous memory and disk footprint -- that the JVM is this super-heavyweight thing that's really just inherently inappropriate for a lot of applications.
- 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.
- danieldk 11y ago
  Until you have enough microservices and each microservice carries its own Go runtime. Then having one JVM suddenly isn't so bad. The problem (as someone else said) is that using Docker may not be the right solution here. There are enough solutions (e.g. servlet containers) where you can run multiple services in one VM, with isolation, and security hardening (using security manager). With regards to memory footprint - the difference here is that Java uses a minimum and maximum heap size that can be tuned with parameters. This has downsides (typically more memory use) and upsides (upper bound on the maximum memory use of a process).
  - publysher 11y ago
    Your remark about isolation is not entirely true: when you run multiple services in one VM, there are still a number of shared resources. Most notably, all services will share the same heap, so one ill-behaved service can bring down all the other services. The only way to prevent this, is to run each service in a separate VM. And at that point, you are once again comparing one Go runtime per service with one JVM per service.
  - politician 11y ago
    > With regards to memory footprint - the difference here is that Java uses a minimum and maximum heap size that can be tuned with parameters. This has ... upsides (upper bound on the maximum memory use of a process). If you're running a Go app in a container, you can use also tune the upper bound on memory use by restricting the available memory for the container.
- sz4kerto 11y ago
  Yes, it's larger than a C or Go process. Does it usually matter? No. The whole Netflix is based on the JVM and Java. They are enormously big, they have high CPU and I/O requirements in many cases, and yet, they manage well on Java. I'm not a big fan of Java as language (to say the least), but the JVM as a runtime is very-very sophisticated.
- benashford 11y ago
  The disk footprint was measuring the size of the docker container, who knows what was in it. Something would have to be wrong for 175 lines to require 650MB of dependencies... it could if it were loading all of Spring/Hibernate/etc., but then I'd challenge it wasn't a "microservice" at all.
  - skarap 11y ago
    JDK... 167MB tarball + 330MB uncompressed
    - threeseed 11y ago
      That's the JDK. You just need the Server JRE which is 57MB tarball + 157MB uncompressed.
  - vonsnowman 11y ago
    Basically Ubuntu 15.04 docker image + openjdk8 + mysqlclient + the service itself
nine_k 11y ago
The idea is that a server this small should probably not consume oodles of memory. They reduced RAM footprint by 100x. Apparently, their Java implementation of this toy service was wildly out of hand. I wish they provided the JVM startup info and stats to compare. Maybe JVM's resource usage could be shrunk, too.
- xienze 11y ago
  > The idea is that a server this small should probably not consume oodles of memory. The number of LOC has no bearing on how much memory something will consume. For all you know the service could just be poorly implemented.
  - nine_k 11y ago
    This is true regarding heap space (you can allocate couple gigs in one line), but perm gen space and JIT space can also be significant in JVM case.
    - threeseed 11y ago
      Permgen space doesn't exist in the JVM any longer. And not sure what JIT space is.
      - mavelikara 11y ago
        I think the OP meant "Code Cache" when they said "JIT space".
- GauntletWizard 11y ago
  As much as I am a fan of go, this sounds like it's a bad build infrastructure more than any fault of Java. JAR shading exists, their imports were probably out of hand (and significantly unused), and while they were microservices, they probably could have had groups of them share a JVM (and benefited from the shared permgen space). Still, that's time and effort, and in Go you get all of those things for free. There's far fewer janky edges (I spent hours figuring out the problems with signed jars, shaded jars, and symlinks when trying to deploy)
vonsnowman 11y ago
As mentioned in the blog post, this was a hackathon project originally, hence the motivation to start with a very small server. The other servers that went through a rewrite also ended up being significantly smaller in go but that's a story for another day.
KirinDave 11y ago
I'm not sure what you'd expect a microservice with a straightforward bit of logic and a single HTTP route to actually cost in terms of lines? I suspect the same (or greater) linecount gains could have been gotten by using a language even more pithy. How much you wanna bet the equivalent Clojure or Scala versio would be half again as many lines?
- jfb 11y ago
  > How much you wanna bet the equivalent Clojure or Scala version would be half again as many lines? 263 lines?
  - KirinDave 11y ago
    Sorry, perhaps poorly worded. Reduced by another 50%, I mean. Clojure is quite terse, and Scala can be when you're using the right toolsets.
pbreit 11y ago
It's merely a positive (to most) data point. Do with it what you wish. Dismissing it outright seems impruduent.
e12e 11y ago
Of course, neither program was actually 175 or 96 LOC -- they included thousands of lines of code from the standard library. Which is why it's possible to "do useful things" in ~200 LOC either in java or go (or python or...). But just because you wrote just 200 LOC, that doesn't free you from bugs and regressions in the remaning thousands of lines of code you rely on. As an anecdote, at a previous work place we had a program that parsed CVS-files for import into an SQL database. This particular program was written by a researcher (meaning: someone with great domain knowledge, but perhaps not a very strong software engineer) in Visual Basic. The program worked great, but we had to upgrade the server that ran it to newer versions of windows, and at some point needed to recompile the code (I don't thing this was releated to a bugfix, IIRC it was simply a run-time/linking issue). As it turned out, the code compiled, but the program didn't work -- MS had changed the API for CVS handling (probably fixing a bug). I don't recall exactly what it was, might have been how floating numbers were parsed/handled, possibly an edge case with Norwegian/English localization or something. Net result, we had a pretty though debugging job on our hands, for a very small program... (I feel a bit bad for singling out MS for this -- as I understand it, they are generally very good about maintaining backwards compatibility -- even to the extent that that becomes a problem. I guess we just hit on a corner case with our use-case and this particular old VB code).

mkozlows 11y ago

The relevance is that even a 175 LOC project in Java takes up enormous memory and disk footprint -- that the JVM is this super-heavyweight thing that's really just inherently inappropriate for a lot of applications.

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.
danieldk 11y ago
Until you have enough microservices and each microservice carries its own Go runtime. Then having one JVM suddenly isn't so bad. The problem (as someone else said) is that using Docker may not be the right solution here. There are enough solutions (e.g. servlet containers) where you can run multiple services in one VM, with isolation, and security hardening (using security manager). With regards to memory footprint - the difference here is that Java uses a minimum and maximum heap size that can be tuned with parameters. This has downsides (typically more memory use) and upsides (upper bound on the maximum memory use of a process).
- publysher 11y ago
  Your remark about isolation is not entirely true: when you run multiple services in one VM, there are still a number of shared resources. Most notably, all services will share the same heap, so one ill-behaved service can bring down all the other services. The only way to prevent this, is to run each service in a separate VM. And at that point, you are once again comparing one Go runtime per service with one JVM per service.
- politician 11y ago
  > With regards to memory footprint - the difference here is that Java uses a minimum and maximum heap size that can be tuned with parameters. This has ... upsides (upper bound on the maximum memory use of a process). If you're running a Go app in a container, you can use also tune the upper bound on memory use by restricting the available memory for the container.
sz4kerto 11y ago
Yes, it's larger than a C or Go process. Does it usually matter? No. The whole Netflix is based on the JVM and Java. They are enormously big, they have high CPU and I/O requirements in many cases, and yet, they manage well on Java. I'm not a big fan of Java as language (to say the least), but the JVM as a runtime is very-very sophisticated.
benashford 11y ago
The disk footprint was measuring the size of the docker container, who knows what was in it. Something would have to be wrong for 175 lines to require 650MB of dependencies... it could if it were loading all of Spring/Hibernate/etc., but then I'd challenge it wasn't a "microservice" at all.
- skarap 11y ago
  JDK... 167MB tarball + 330MB uncompressed
  - threeseed 11y ago
    That's the JDK. You just need the Server JRE which is 57MB tarball + 157MB uncompressed.
- vonsnowman 11y ago
  Basically Ubuntu 15.04 docker image + openjdk8 + mysqlclient + the service itself

nine_k 11y ago

The idea is that a server this small should probably not consume oodles of memory. They reduced RAM footprint by 100x. Apparently, their Java implementation of this toy service was wildly out of hand. I wish they provided the JVM startup info and stats to compare. Maybe JVM's resource usage could be shrunk, too.

xienze 11y ago
> The idea is that a server this small should probably not consume oodles of memory. The number of LOC has no bearing on how much memory something will consume. For all you know the service could just be poorly implemented.
- nine_k 11y ago
  This is true regarding heap space (you can allocate couple gigs in one line), but perm gen space and JIT space can also be significant in JVM case.
  - threeseed 11y ago
    Permgen space doesn't exist in the JVM any longer. And not sure what JIT space is.
    - mavelikara 11y ago
      I think the OP meant "Code Cache" when they said "JIT space".
GauntletWizard 11y ago
As much as I am a fan of go, this sounds like it's a bad build infrastructure more than any fault of Java. JAR shading exists, their imports were probably out of hand (and significantly unused), and while they were microservices, they probably could have had groups of them share a JVM (and benefited from the shared permgen space). Still, that's time and effort, and in Go you get all of those things for free. There's far fewer janky edges (I spent hours figuring out the problems with signed jars, shaded jars, and symlinks when trying to deploy)

vonsnowman 11y ago

As mentioned in the blog post, this was a hackathon project originally, hence the motivation to start with a very small server. The other servers that went through a rewrite also ended up being significantly smaller in go but that's a story for another day.

KirinDave 11y ago

I'm not sure what you'd expect a microservice with a straightforward bit of logic and a single HTTP route to actually cost in terms of lines? I suspect the same (or greater) linecount gains could have been gotten by using a language even more pithy. How much you wanna bet the equivalent Clojure or Scala versio would be half again as many lines?

jfb 11y ago
> How much you wanna bet the equivalent Clojure or Scala version would be half again as many lines? 263 lines?
- KirinDave 11y ago
  Sorry, perhaps poorly worded. Reduced by another 50%, I mean. Clojure is quite terse, and Scala can be when you're using the right toolsets.

pbreit 11y ago

It's merely a positive (to most) data point. Do with it what you wish. Dismissing it outright seems impruduent.

e12e 11y ago

Of course, neither program was actually 175 or 96 LOC -- they included thousands of lines of code from the standard library. Which is why it's possible to "do useful things" in ~200 LOC either in java or go (or python or...). But just because you wrote just 200 LOC, that doesn't free you from bugs and regressions in the remaning thousands of lines of code you rely on. As an anecdote, at a previous work place we had a program that parsed CVS-files for import into an SQL database. This particular program was written by a researcher (meaning: someone with great domain knowledge, but perhaps not a very strong software engineer) in Visual Basic. The program worked great, but we had to upgrade the server that ran it to newer versions of windows, and at some point needed to recompile the code (I don't thing this was releated to a bugfix, IIRC it was simply a run-time/linking issue). As it turned out, the code compiled, but the program didn't work -- MS had changed the API for CVS handling (probably fixing a bug). I don't recall exactly what it was, might have been how floating numbers were parsed/handled, possibly an edge case with Norwegian/English localization or something. Net result, we had a pretty though debugging job on our hands, for a very small program... (I feel a bit bad for singling out MS for this -- as I understand it, they are generally very good about maintaining backwards compatibility -- even to the extent that that becomes a problem. I guess we just hit on a corner case with our use-case and this particular old VB code).