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 <[email protected]> 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 [email protected] .
> 
> 
> ------------
> 
> Austin Jackson 
> [email protected] <mailto:[email protected]>

Reply via email to