performance of less compilation
Jim Laskey (Oracle)
james.laskey at oracle.com
Mon Jun 24 05:10:58 PDT 2013
Thanks for the heads up. JDK8 is only API frozen, so we have some time to address performance issues as they come up. There are some fixes in the pipe that will address some of the things I see here, but we should examine in more detail. Therefore, I have a few questions and comments.
How did you run less-1.3.3.min.js independently of DOM/CSS? Running straight up I get several reference errors. Would you post the exact code you used to produce these results?
The chart you provide doesn't show Nashorn JDK7 completing. How did it fail? It is possible that Nashorn might converge differently than Rhino (focus on server side.) I'll see if I can get an in house version of JDK7 to run (we don't use the github back port - it has issues.)
You should also note that there is a bug in JDK7 javax.script that causes javascript to be chosen randomly (rhino/nashorn.) This has been addressed in later releases (fix is in the pipe.)
Comparing JDK 7 and JDK 8 is apples and oranges at this point. JDK8 suffers a high start up cost of JSR-292 Lambda Forms. There is also a fix in the pipe for this.
So, let's start with how to run the tests and see where we get from there.
Cheers,
-- Jim
More information about the nashorn-dev
mailing list