The Great Startup Problem

[Jochen Theodorou]

Am 24.08.2014 20:33, schrieb Charles Oliver Nutter:
> On Sun, Aug 24, 2014 at 12:55 PM, Jochen Theodorou <blackdrag at gmx.org> wrote:
>> 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?
>
> Forcing all handles to compiler early has the same negative
> effect...most are only called once, and the overhead of reifying them
> outweighs the cost of interpreting them.
>
> I need to play with it more, though. The property I think you're
> referring to did not appear to help us much.

I see it as a tradeoff. Yes, one-time-visited callsites may run even 
slower with this, but I think that is to be measured first. And 
secondly, you will be up to speed much faster than before, which can 
maybe outweight the initial cost. I am not saying 1 is an ideal value, 
but it should be played with.

>>> 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?
>
> Perhaps 10x faster startup across the board in C Ruby. With tier 1 we
> can get it down to 5x or so. It's incredibly frustrating for our
> users.

I guess for a rails app that is indeed pretty bad.

>> All in all, the situation is for the Groovy world quite different I would
>> say.
>
> I'd guess that developers in the Groovy world typically do all their
> development in an IDE, which can keep a runtime environment available
> all the time. Contrast this to pretty much everyone not from a Java or
> C# background, where their IDE is a text editor and a command line.

Now I feel almost insulted ;) I get scolded so often, that I treat my 
IDE only as a better text editor... I agree in general though.
I think this is not so much a Groovy thing, as more a java thing though. 
If you do Grails, you do Spring+Apache most of the time. So you don't 
start a new server, you deploy to it. And even that may (in development 
mode) work by just keeping the class files in a certain directory. Unit 
testing is maybe different. But even there, you don't start a new JVM 
for each test. Maybe not even for each test suite. Groovy generally goes 
with the JVM instance here. Actually it is not even easily possible to 
spawn separate Groovy environments in the same JVM. In Grails a new 
environment might be spawned on a per suite base.

So yes, there are instances kept around, but imho this is already done 
from the Java world. We do nothing special here most of the time. But of 
course this is related to slow startup speeds of the JVM. groovy-core 
has around 7k tests, if for each of them we would have to create a new 
JVM it would easily take over an hour to execute. With Groovy startup 
included probably more than 6 hours.

Yes, this is a result of the great startup problem. But, the Java 
community finds ways around. The problem is that in JRuby you have to 
try to force a Ruby mechanism onto the JVM. And this works properly only 
if the JVM can behave as much as the Ruby as needed. And in regards to 
the startup times it does surely not.

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