performance of less compilation

[Ivo Houbrechts]

> 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


> 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)

> 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.

> 
> 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

Grtz,
Ivo