Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The JVM is not that heavy

opensourcery.co.za

Post reply on HN
Print view View original

211–220 of 373 posts

Re: The JVM is not that heavy

#211

Post by hardwaresofton »

I was a little surprised that he author disliked "heavy" things, yet kept reaching for the absolute heaviest tools in their respective categories:

- Rails (just about the heaviest web framework ever made for ruby, despite it's wide appeal)

- Ember (I absolutely love ember, but it is by far the heaviest modern JS framework... I don't include things like ExtJS)

Also, I routinely use the heavy/light distinction, but it seems in a completely different way. I almost don't care how heavy something that run on the server-side of a web application is, on the back-end "heavy" generally translates to "contains complexity I'm not willing to deal with". "heavy" on the frontend for me means both in footprint and complexity.

Re: The JVM is not that heavy

#212

Post by cbsmith »

geocar wrote: post #144
gregschlom wrote: post #25

Also worth noting that the JVM itself only weighs a couple of megabytes. The bulk of the size comes from the Java runtime (ie: the "standard libraries"), and there are lots of things that your app may not need there (XML parsing, serialization, etc...) A couple of years ago I wrote a simple tool ( https://github.com/aerofs/openjdk-trim ) that allows you to filter out what you don't need. We were able to get the size…

I don't know. 10MB still sounds really too big. Why is it so big? What do we gain? I don't have a system with 10MB of cache, so I imagine Java can't run faster than memory...

Huh? What?

Several points:

* Who said the 10MB is all used at once?

* I don't know your hardware, but there is very, very good chance you are actually quite wrong about * If you were referring strictly to CPU cache, then I'm even more confused, because the entire existence of that stuff is predicated on it being faster than memory, so... (and even still, if your total CPU cache isn't 10MB, it likely isn't that much smaller).

* It's not like the whole package would sit in RAM the whole time anyway. By your same assertion, I could say that one of my CPU registers is only 64-bits wide, so I imagine all programs larger than 64-bits can't run faster than L3 cache...

I'm not sure why you'd say it is too big. The article page is 1.4 MB alone... and it still needs to leverage a general purpose runtime/JIT that is orders of magnitude larger to do its single fixed purpose.

Re: The JVM is not that heavy

#213

Post by hota_mazi »

geocar wrote: post #144
gregschlom wrote: post #25

Also worth noting that the JVM itself only weighs a couple of megabytes. The bulk of the size comes from the Java runtime (ie: the "standard libraries"), and there are lots of things that your app may not need there (XML parsing, serialization, etc...) A couple of years ago I wrote a simple tool ( https://github.com/aerofs/openjdk-trim ) that allows you to filter out what you don't need. We were able to get the size…

I don't know. 10MB still sounds really too big. Why is it so big? What do we gain? I don't have a system with 10MB of cache, so I imagine Java can't run faster than memory...

> I don't know. 10MB still sounds really too big.

Can't tell if sarcastic or... o_O.

In the unlikely case you're actually serious, you really need to rethink your perception of memory costs in 2017.

Re: The JVM is not that heavy

#214

Post by hota_mazi »

brianwawok wrote: post #96
martingxx wrote: post #46

I led our teams to switch from Java to Go because of the productivity of development, but then noticed deployment was simpler and faster, memory usage was slashed (for comparable applications), request/response times were much more consistent, startup was practically instant and as a result we started aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to ru…

> aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to run in AWS. This is the easy trap to fall into though. What if you aggressively rewrote the Java apps from crappy legacy frameworks to well developed Java apps? A rewrite ALMOST always is faster. So the new language seems faster. Except if you would then rewrite the rewrite back in the original languag…

> This is the easy trap to fall into though.

Indeed.

It's a typical honeymoon phase with very little regards to 1-2-5 years in the future. The cost of having picked to Go will be fully apparent then.

Re: The JVM is not that heavy

#215

Post by hota_mazi »

nostrademons wrote: post #176
martingxx wrote: post #110

Earlier quoted context omitted.

These apps are mostly microservices and the Java ones are mostly only a year or two old. None of them use things like spring. Some use Dropwizard. Would you consider dropwizard modern? If not, what would you use instead?

Take a look at the TechEmpower benchmarks: https://www.techempower.com/benchmarks/ DropWizard is modern, but it isn't fast. Go and even Node.js are significantly faster. If you want performance, you cut layers out of the stack - check out the numbers for raw servlets or even just straight Jersey annotations in that benchmark. If I were doing JSON-over-HTTP microservices in Java, I'd likely use straight Jersey + Jacks…

> DropWizard is modern, but it isn't fast. Go and even Node.js are significantly faster.

Any benchmarks to provide in order to support this wild claim?

Re: The JVM is not that heavy

#217

Post by nostrademons »

hota_mazi wrote: post #215
nostrademons wrote: post #176

Earlier quoted context omitted.

Take a look at the TechEmpower benchmarks: https://www.techempower.com/benchmarks/ DropWizard is modern, but it isn't fast. Go and even Node.js are significantly faster. If you want performance, you cut layers out of the stack - check out the numbers for raw servlets or even just straight Jersey annotations in that benchmark. If I were doing JSON-over-HTTP microservices in Java, I'd likely use straight Jersey + Jacks…

> DropWizard is modern, but it isn't fast. Go and even Node.js are significantly faster. Any benchmarks to provide in order to support this wild claim?

The ones I just linked to above.

Re: The JVM is not that heavy

#218

Post by jpgvm »

hyperpallium wrote: post #168
fetbaffe wrote: post #112

Earlier quoted context omitted.

Yes, the limitation is rarely the programming language, it is the programmer. Also, when you do the rewrite you have already solved the domain problem that you did not fully understand when implementing it the first time.

"Plan to throw one away; you will, anyhow." First version to understand the problem, second version to solve it. But deployment, gc pauses and startup time (jvm vs go) are orthogonal to program quality. I would also expect go to have less memory usage. > deployment was simpler and faster, memory usage was slashed..., request/response times were much more consistent, startup was practically instant

Orthogonal to quality but imperative to velocity.

At the end of the day despite Go's failings it's a good (maybe the best?) language for large projects and teams because it compiles fast, is easy to anyone to run anywhere, tests run quickly, programs execute quickly and there is already good tooling/editor support.

Nothing beats efficient workflow for improving velocity.

Re: The JVM is not that heavy

#219

Post by abvdasker »

jmspring wrote: post #208

I've never had a problem with Java the language being heavy. However, many code bases due to annotations, dependency injection, etc. from a development perspective really aren't any longer Java. You need to understand the code base, the app itself, etc. This happens with open source projects as well. I contributed to the Azure support for JClouds and the bulk of my ramp up time was understanding how things were done…

I could not agree with you more. My most recent job doing Java dev at a major US tech company has really soured me on this style of Java. Annotations beyond null/nonnull seem to obscure the code and make it far less maintainable. Besides being largely superfluous the DI frameworks — primarily Dagger — I've seen widely used at said company have led to numerous production memory leaks because they obscured object scope and lifecylce from engineers.

Re: The JVM is not that heavy

#220

Post by zapov »

nostrademons wrote: post #176
martingxx wrote: post #110

Earlier quoted context omitted.

These apps are mostly microservices and the Java ones are mostly only a year or two old. None of them use things like spring. Some use Dropwizard. Would you consider dropwizard modern? If not, what would you use instead?

Take a look at the TechEmpower benchmarks: https://www.techempower.com/benchmarks/ DropWizard is modern, but it isn't fast. Go and even Node.js are significantly faster. If you want performance, you cut layers out of the stack - check out the numbers for raw servlets or even just straight Jersey annotations in that benchmark. If I were doing JSON-over-HTTP microservices in Java, I'd likely use straight Jersey + Jacks…

Boon is not that fast. It only appears fast on some poorly constructed benchmarks due to some lazy benchmarketing optimizations.

https://github.com/fabienrenaud/java-json-benchmark

Post reply on HN