Bernd, Thanks for your advice on this.
I do not enjoy benchmarking; I enjoy simplicity, and a customer with a Java-based stack, lots of JavaScript programmers working on the client, and a desire to migrate toward scripting languages should use Nashorn, because it's by far the simplest path forward. But the objection I got was "there are performance concerns," with no evidence presented. So I'd want to (a) create a minimal amount of evidence, (b) use profiling exactly like you're suggesting to do a bit of bottleneck elimination of proof-of-concept code before presenting it. Because the first evaluation customer would do would be to load test it, and I'd want to be prepared. I anticipate bottlenecks would have nothing to do with Nashorn (there are no DBAs, so the database is not exactly optimized), but I'd like to have some metrics to demonstrate that. I agree that I would not use the profiler to do performance benchmarking, given that the profiler adds overhead in the first place. :) -- David. On Thu, Oct 2, 2014 at 2:21 PM, Bernd <[email protected]> wrote: > 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/ >>
