Converting from JFX Webview to Nashorn. Performance trouble

Marcus Lagergren marcus.lagergren at oracle.com
Sat Oct 25 18:41:42 UTC 2014


Any micro/minibenchmarks that you can extract would be very helpful indeed - i.e. those that have similar workloads like your code, but are NDA safe.

There are several performance improvements in the 8u40 if you run with —optimistic-types=true, at the cost of larger warmup (unless you use the code cache). That might help.

Regards
Marcus

> On 24 Oct 2014, at 19:13, Jenks, Robert <rjenks at ti.com> wrote:
> 
> Unfortunately I cannot share code without an NDA, but let me ask up the
> management ladder to see what they want to do.
> 
> I agree about Jav8.  Which is why it was lower priority than Nashorn to
> test.  Fortunately there is very little interaction between Java and
> Javascript needed for our app.
> 
> So without disclosing what I¹m working on, let me describe a similar
> application.  Imaging that I am working on a GameBoy Emulator.  In this
> case I would have a processor emulator written in Javascript and the ROM
> as a byte array.  The only interaction needed are to inject key events and
> to get screen updates using screen buffer in virtual memory (javascript
> array).  Most of the Javascript is tiny functions which implement
> processor opcodes.  These opcode functions are all annonymous and stored
> in an array indexed by the opcode.
> 
> -Robert
> 
> On 10/24/14, 12:03 PM, "Jim Laskey (Oracle)" <james.laskey at oracle.com <mailto:james.laskey at oracle.com>>
> wrote:
> 
>> Robert,
>> 
>> Well, as with any port there has to be localized tweaking.  We'd be
>> willing to help you profile and find the bottlenecks.  This also helps up
>> find areas we need to improve.
>> 
>> Warning about JaV8, as far as I am aware there hasn't been a lot of
>> activity on JaV8 of late.  The JNI support was very weak.
>> 
>> Cheers,
>> 
>> -- Jim
>> 
>> 
>> 
>> 
>> On Oct 24, 2014, at 1:04 PM, Jenks, Robert <rjenks at ti.com> wrote:
>> 
>>> After getting back from JavaOne and being excited about Nashorn I
>>> decided to try porting our large javascript app to work under Nashorn.
>>> Currently we have a JavaFX application with a WebView component where we
>>> load our HTML/CSS/Javascript application.  In WebView performance has
>>> been about half of what we need it to be.  The Javascript application is
>>> large, very CPU intensive.  It does draw to a canvas, but the drawing is
>>> very simplistic and infrequent.
>>> 
>>> I completed the port and have been experimenting with it.  So far, I am
>>> disappointed with the results.  I expected additional startup delays due
>>> to the JIT, but even after the application is warmed up and the JIT
>>> compilation threads go idle, the application is running about twice as
>>> slow as the WebView version.  I even tried using Java 9 EA and it did
>>> help some, but it¹s still no where near as fast.
>>> 
>>> I suspect that most of the performance advantages Nashorn gives are
>>> related to using the Nashorn (Java) canvas implementation.  Since our
>>> app isn¹t hindered by canvas performance, this doesn¹t help.  Another
>>> interesting observation is that Nashorn is using a HUGE amount of heap
>>> space.  Our app uses about 300-500MB using the WebView approach, but 3GB
>>> under Nashorn.
>>> 
>>> So, unless someone has a suggestion I think I¹m going to move on to
>>> trying to get V8 running through the Jav8 project.  Since our
>>> application performs well in Chrome this is about the last option beyond
>>> rewriting out app in C or Java.
>>> 
>>> -Robert



More information about the nashorn-dev mailing list