Am 24.08.2014 20:33, schrieb Charles Oliver Nutter:
On Sun, Aug 24, 2014 at 12:55 PM, Jochen Theodorou <blackd...@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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
