The Great Startup Problem

[Jochen Theodorou]

Am 22.08.2014 22:08, schrieb Charles Oliver Nutter:
[...]
> 2. Lambda forms are too slow to execute and take too long to optimize
> down to native code. Lambda forms work sorta like the tiered compiler.
> They'll be interpreted for a while, then they'll become JVM bytecode
> for a while, which interprets for a while, then the tiered compiler's
> first phase will pick it up.... There's no way to "commit" a lambda
> form you know you're going to be hitting hard, so it takes FOREVER to
> get from a newly-bootstrapped call site to the 5 assembly instructions
> that *actually* need to run.

afaik you can set how many times a lambda form has to be executed before 
it is compiled... what happens if you set that very low... like 1 and 
disable tiered compilation?

[...]
> We obviously still love working with OpenJDK, and it remains the best
> platform for building JRuby (and other languages). However, our
> failure as a community to address these startup/warmup issues is
> eventually going to kill us. Startup time remains the #1 complaint
> about JRuby, and warmup time may be a close second.

how do normal ruby startup times compare to JRuby for a rails app?

> What are the rest of you doing to deal with these issues?

It depends on the usage I guess.

For command line utilities even the startup time of a pure JVM used to 
be too slow. For that kind of work something like Drip can help, since 
it is only a small VM that is needed. And there is no need to have it 
going to some kind of optimized state first. The next bigger application 
with some kind of approach like that is Grails, and it seems to work for 
them, though they don't use drip, afaik they use a client-server system 
for this.

Most comparable to Rails in the Groovy world would be Grails I guess. 
But there is a huge amount of Java involved, so that there is maybe no 
compare. Also the style of applications is different.... Ruby used not 
really to know about multithreading so it was normal to just fork and 
things like that. And ultimatively, we have no Rails to compete with in 
Groovy.

All in all, the situation is for the Groovy world quite different I 
would say.

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org