Converting from JFX Webview to Nashorn. Performance trouble

[Jenks, Robert]

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>
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
>