5 ms·
I don't think the author did a particularly good job of addressing the points about startup time or memory size. In particular, I think the argument about memo
by weberc2 10y ago
I don't think the author did a particularly good job of addressing the points about startup time or memory size.
In particular, I think the argument about memory consumption is that it's independent of compilation strategy, but rather it depends on the quality and tuning of the garbage collector. An AOT compiled program that uses the default JVM GC with default tunings will not see much better memory performance (unless the memory consumption is dominated by the JIT).
On the other hand, I think the "AOT improves startup times" argument is a good one, and the author's explanation was unsatisfactory: AOT Java programs don't start any faster than JVM programs. What is the methodology for testing? Is he using the later-mentioned Avian? Because that tool deliberately trades startup time for small binaries (via compression). Even if he isn't, it's likely a matter of tool maturity--there's no fundamental reason an AOT Java Hello World should be slower than a golang hello world (which clocks in at 50ms on my machine compared to 130ms for JVM). Also the author implies that startup times only matter for tiny unix tools--I'd like to counter with a practical example: Gradle is so slow to start up that it's been daemonized. I don't know if this satisfies the author's characterization of "tiny unix tools" or not, but clearly start up times matter.
- mike_hearn 10y agoI don't think (?) I said AOT programs don't start any faster than JIT compiled programs. I said Hello World doesn't start any faster when AOTd, because being able to avoid JITing a few methods (on a spare unused core) is not worth the increase in page faults needed to load the larger code from disk. But that's probably rather specific to Hello World. I'd hope real programs see faster startup! Gradle is so slow to start up that it's been daemonized. Gradle is usually run from the command line, so surely that supports my point? (perhaps emphasising the "tiny" was a mistake). At any rate, Maven doesn't have the same problem, despite doing the same task. Gradle is slow to start for a lot of reasons.
- weberc2 10y ago> I don't think (?) I said AOT programs don't start any faster than JIT compiled programs. You're right; I paraphrased poorly. I think my point stands--there's no reason an AOT compiled Java Hello World should be slower than a Go Hello World, which is nearly 3 times faster than the JVM version on my machine. > Gradle is usually run from the command line, so surely that supports my point? I assumed that Gradle was slow to start for JIT warmup and the like. It's hard to believe that daemonizing is the performance solution if the bottleneck is in the application (for example, if file parsing is the bottleneck, the natural solution would be to cache the parse result). Maybe my assumption is bad?
- mike_hearn 10y agoThe daemon is mostly about caching the configuration, yes. It caches JIT compiled code too, but Gradle configuration is actually a big pile of Groovy scripts that create objects, or something like that, and scripting languages are slower to start up even than interpreted Java.
- vorg 10y ago> Gradle configuration is actually a big pile of Groovy scripts that create objects You can now configure Gradle (since v 3.0) using Kotlin instead of Apache Groovy. That might speed up Gradle start up times.
- sitkack 10y agoHello World. You used Hello World as an example for anything.