performance of less compilation
ivo at houbrechts-it.be
Tue Jun 25 13:11:09 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 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.
PerformanceComparison.groovy in src/test/groovy was used as a basis for the test runs to compile the bundled bootstrap less
> 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.)
I explicitly load the engine by name and I don't think I ran into this.
> 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
More information about the nashorn-dev