UglifyJS performance

[Marcus Lagergren]

Hi Austin!

Is this particular timing when you are uglifying the jquery test script that you supplied? I do a full Nashorn run, and I indeed see a slowdown that probably shouldn’t be there. There are several sources of overhead and no _huge_ single low hanging fruit, as far as I can tell (damn).

To figure this out, I did a run to produce a Mission Control recording and inspected it.

java -XX:+UnlockCommercialFeatures -XX:+FlightRecorder -XX:FlightRecorderOptions=defaultrecording=true,disk=true,dumponexit=true,dumponexitpath=recording.jfr,stackdepth=1024 - -jar chisel.jar compile uglify -i test-files/jquery-2.1.1.js -o output.js

There is field guard overhead, and there are a few megamorphic fields, but none of this take up more than 15% of the runtime. 

I’ll file this a bug and have someone dive deeper.

Thanks a lot for the report! Much appreciated.

/M

> On 15 Dec 2014, at 04:15, Austin Jackson <themacphage at gmail.com> wrote:
> 
> Hello! I’m Austin and I like Nashorn.
> 
> I was prompted by @lagergren <https://twitter.com/lagergren/status/543526837293711360> to share something with you all that might be of use. I love the work that you all have done with Nashorn making it easy to write JavaScript code and utilize standard Java classes — it’s absolutely great!
> 
> I, personally, have been using Nashorn to try and run NodeJS modules under it, particularly UglifyJS2.
> 
> All the files I mention following this are available in a Github release below of my app I’m hoping to use Nashorn with. There is a executable Jar file with the correct directories and instructions on how to run on the website below. The source code is available here below, also.
> 
> My app is currently a test that wraps UglifyJS2 with bindings in net.austin.chisel.wrappers.UglifyWrapper.java. You can ignore the LESS stuff because that runs on Rhino and isn’t my library (it’s here <https://github.com/marceloverdijk/lesscss-java>).
> 
> The important thing is that when I run UglifyJS2 natively under NodeJS (V8), then the compile time is around 1 second more or less (I had no way to time it, that I knew of), but when I run my wrapper, it takes around 47.5 seconds to do the same! However, the resulting copies are verbatim and Nashorn functioned entirely correct, just a big performance problem. @lagergren <https://twitter.com/lagergren/status/544231448900034561> said this might be a warm-up issue.
> 
> For clarity, I’m running what I believe to be the newest public release of the JDK/JRE. I’m on OS X Yosemite. When I run java -version I get this:
> 
> java version "1.8.0_25"
> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
> 
> Github release: https://github.com/MacPhage/chisel/releases/tag/v0.0.1 <https://github.com/MacPhage/chisel>
> Binaries (direct ZIP): chisel-0.0.1-bundle.zip <https://github.com/MacPhage/chisel/releases/download/v0.0.1/chisel-0.0.1-bundle.zip>
> Source code (direct ZIP): Source code (zip) <https://github.com/MacPhage/chisel/archive/v0.0.1.zip>
> Github source code at specified commit: https://github.com/MacPhage/chisel/tree/e81ddee8e339d3717beda1ed8a675568be245c22 <https://github.com/MacPhage/chisel/tree/e81ddee8e339d3717beda1ed8a675568be245c22> 
> 
> 
> If you have any more questions regarding my setup, please tweet me @au5ton <https://twitter.com/au5ton> or email themacphage at gmail.com .
> 
> 
> ------------
> 
> Austin Jackson 
> themacphage at gmail.com <mailto:themacphage at gmail.com>