performance of less compilation

[Jim Laskey (Oracle)]

On 2013-06-25, at 5:11 PM, Ivo Houbrechts <ivo at houbrechts-it.be> 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