If you're installing a compiler on your production server, you're doing it wrong.
And yet we do that every time we install the JVM (and Ruby, and Python, and...)
The JVM is not that heavy
141–150 of 373 posts
Re: The JVM is not that heavy
#142A lot of Java apps are shit at packaging too. They often include an entire Tomcat server with all the setup files you don't even need. I wrote this a while ago:
http://penguindreams.org/tutorial/embed-tomcat-in-your-appli...
..but don't do that. Instead use something newer like netty and ditch that decades old crappy servlet layer you don't need.
You can also use sbt+onejar or sbt-native-package to make either a single jar runnable or a standard deb/rpm/tar.gz package to run your service.
Re: The JVM is not that heavy
#143I agree with many points in this article. That being said, there are dimensions of heaviness not captured in the article as far as I can see: 1. The startup times, not so much of the JVM itself, that just takes 1,5 secs, but the startup time of your application gets higher if you have a lot of classes on the classpath. I guess it's the classpath scanning that takes a lot of time (?). 2. Memory usage of Java objects i…
Did you test that 1.5 second claim yourself? I literally just wrote a HelloWorld and ran it on my MacBook, the total time for the whole program was <0.2 seconds.
I agree that my claim is false. I kind of wrote that from the top of my head.
In any case, the point that I wanted to make in the parent comment was that the JVM startup time itself was basically fine.
I just checked on my Macbook and a HelloWorld class gives me .13 secs real.
Re: The JVM is not that heavy
#144Also 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...
Re: The JVM is not that heavy
#145Earlier quoted context omitted.
That links says 1.2 seconds for a hello world! 1.2 microseconds is what I would expect to be called fast.
Please be kind to reread it. Startup time of a simple Java application and therefore also whole JVM is 0.4s (in the linked article). 1.2s is for the implementation in Closure that includes its additional quite heavy runtime.
I read it fine, but Clojure is an application of the JVM. The fact that a popular interpreted language of the JVM takes 1.2 seconds for hello world is a problem of the JVM itself, or at least it's ecosystem. An interpreted language in C wouldn't take nearly that long.
Re: The JVM is not that heavy
#146Also 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…
Proguard is de-facto standard for Android Java ecosystem, what's the difference OpenJDK-Trim has? Except that Proguard determines used/unused classes automatically, by doing static code analysis, so you need to have proguard config to omit removing stuff that is used dynamically, of course.
Re: The JVM is not that heavy
#147I agree with many points in this article. That being said, there are dimensions of heaviness not captured in the article as far as I can see: 1. The startup times, not so much of the JVM itself, that just takes 1,5 secs, but the startup time of your application gets higher if you have a lot of classes on the classpath. I guess it's the classpath scanning that takes a lot of time (?). 2. Memory usage of Java objects i…
> The heavyness of the ecosystem in terms of the magnitude of concepts and tools being used and the enterprisy-ness of libraries. You don't have to use the enterprisey libraries though. Using Dropwizard, for example, gives you a tight and performant set of libraries that have a fairly minimal learning curve and require relatively little boilerplate.
I mean, even the "enterprisey" stuff like Spring Boot is more than fast enough. I have a little REST service I just deployed to production today, 5 seconds to start up on my laptop's SSD (unfortunately it took about 50 seconds in production because our SAN is dog-slow for some reason).
Re: The JVM is not that heavy
#148Java, especially JAR files, can be quite light weight. However, JVM environments, and development with Java and Clojure, can be very heavy _and_ slow.
For Clojure, starting `lein repl`, takes 16 seconds on my 2012 Macbook and 9 seconds on my similarly-aged Dell laptop, both with SSDs and i7 quads.
Regarding memory usage examples, the base memory usage of a Google App Engine instance running the move trivial Hello World Java program takes around 140MB. Given that the default F1 instance has a soft memory limit of 128MB, it becomes clear that the JVM is working against you in both cost effectiveness (the price to spin up new instances as your existing ones are already above the soft limit) and latency (since spinning up instances is slow). Add Clojure on top and the problem certainly doesn't get any better. As an added annoyance, which is specific to App Engine but a result of using the JVM, it's impossible to specify JAVA_OPTS, so any of the -X flags, without switching to the Flexible environment.
As a result of both of the above, choosing Clojure for developing on App Engine, as my specific example, has had the serious downfall of slow development tools and memory issues out of the gate on my instances, causing me to pay more for a beefier instance class. The REPL is really hard to beat, but the combination of JVM and Clojure are the biggest pain in the ass, with this stack.
Re: The JVM is not that heavy
#149Java, especially JAR files, can be quite light weight. However, JVM environments, and development with Java and Clojure, can be very heavy _and_ slow. For Clojure, starting `lein repl`, takes 16 seconds on my 2012 Macbook and 9 seconds on my similarly-aged Dell laptop, both with SSDs and i7 quads. Regarding memory usage examples, the base memory usage of a Google App Engine instance running the move trivial Hello Wor…
Yes, the startup is slow. But nothing afterwards is. The JVM gets bad press because of startup time while in reality that hardly matters.
Re: The JVM is not that heavy
#150What most people seem to miss is that if you use Clojure, the startup time hardly matters, because you do not restart your development JVM often.
I find this similar to discussions about boot time. It doesn't matter -- I reboot my computer once a month, if even that.