On 2013-06-25, at 5:11 PM, Ivo Houbrechts <[email protected]> wrote:
>> 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 source code is on github: https://github.com/houbie/lesscss/tree/nashorn, > in the nashorn branch > The main class is LessCompiler.java, which can compile an input fie to an > output file. > The project is build with gradle 1.6, but since it has only one test > dependency, it can be compiled/executed straight from an IDE. > The src/main/resources/js directory contains the 3 javascript files that get > merged and compiled: environment.js (minimal stubs for browser/dom), > less-1.3.3(.min).js and compile.js (java callback functions) > > PerformanceComparison.groovy in src/test/groovy was used as a basis for the > test runs to compile the bundled bootstrap less Thanks. It will be a few days before we can look at this. Half the team is on vacation (I'm off the next 5 days) and we are trying to get thru planning and the last few bugs. Stay tuned. > > >> 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.) > > It failed with a javascript error (don't remember the exact error) during the > 3th run within the same context, but I wouldn't bother too much because the > back port is based on an older Nashorn version (although I was intrigued by > the fact that it was faster then jdk8 for the first 2 runs) We'll see if we can work around that issue (if it still exists.) > >> 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.) > > I explicitly load the engine by name and I don't think I ran into this. Good. > >> >> 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. > > As you can see in PerformanceComparison.groovy, I started to measure after > creating the compiler object, so jdk startup should not matter. Furthermore, > when I run the code from the master branch, that uses Rhino 1.7R4, I get the > same results in both jdk7 and jdk8 I'm talking specifically about Lambda Form start up (lazily initialized) for JSR-292 on JDK 8. Charles Nutter has commented on this issue as well for jRuby. > > Grtz, > Ivo > Cheers, -- Jim
