4 ms·
> 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
by 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.