Hello David, Do you want to optimize the JVM settings before challenging V8 or do you hope to get absolute measurements with the profiler to show off?
Because I would advice against using profilers for anything besides optimizations, finding hotspots and doing before/after comparision or trends. For the shootout an externally driven metric (req/s, 99%th service times) is a guess better. And particular on bigger machines (which I would expect to be the NodeJS bottleneck - not sure if Avatar.JS does this better). Gruss Bernd Am 25.09.2014 23:24 schrieb "David P. Caldwell" < [email protected]>: > Team, > > When I attempt to connect the NetBeans profiler (which I understand to > be essentially the same as jvisualvm) to a Nashorn embedding, I get an > error (JVMTI error 62) for essentially every class that relates to > scripting, including the dynalink stuff and Nashorn itself, as well as > generated classes named NashornJavaAdapter. > > If I persist through all of this (or filter them out of being > profiled, or turn on -Xverify:none), I end up with profiling data that > doesn't involve the JavaScript code at all; it basically treats the > call to eval() as atomic. > > Do you guys do this stuff? My customers are constantly objecting to > the "fact" that running Java on the JVM is going to be a terrible > idea, performance-wise -- especially compared to Node, which they > believe is lightning fast -- and I am having difficulty generating > data on this point. > > More generally, of course, profiling is a normal and necessary > development activity. I wrote a Java agent for Rhino that mangled the > classes using Javassist to wrap all JavaScript function invocations in > instrumented methods, but I'm not clear on (a) whether that's > necessary, or (b) how it would work given the Nashorn implementation > is probably using constructs I don't yet understand. But if that's the > route, let me know and give me a pointer or two and I'll be on my way. > > -- David P. Caldwell > http://www.davidpcaldwell.com/ >
