Thank you. On Oct 27, 2014, at 3:43 PM, Jenks, Robert <[email protected]> wrote:
> I am working on the NDA and I think it should be possible. If not, I will > work on a relevant benchmark script. > > Thanks for the info on the optimistic types. I will give that a try. > > -Robert > > From: Marcus Lagergren <[email protected]> > Date: Saturday, October 25, 2014 at 1:41 PM > To: Robert Jenks <[email protected]> > Cc: "Jim Laskey (Oracle)" <[email protected]>, > "[email protected]" <[email protected]> > Subject: Re: Converting from JFX Webview to Nashorn. Performance trouble > > 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 <[email protected]> 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)" <[email protected]> >> 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 <[email protected]> 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 >
