Part of the performance work requires us moving to a more lazy execution model, which should bring part of the bootstrapping problem away. At the time I can't say if this is 8.0 or the first service upgrade, though.
/M On Oct 14, 2013, at 2:58 PM, Tal Liron <[email protected]> wrote: > Performance per se is hard to test in data-driven web applications: the > complete route uses the database, which is always orders of magnitude slower > than that of the code execution. And in Prudence, the cache is handled > entirely in Java code, so it won't even run any Nashorn when pulling pages > from the cache. I may need to devise a different kind of test, more > CPU-bound, specifically to benchmark Nashorn vs. Rhino. If you guys have any > ideas (possibly that you are using in Avatar.js?) I'd be happy to try them. > > However, I do some have news for the bootstrapping process (based on > Sincerity). And the news is not good: Nashorn takes significantly longer to > compile than Rhino, resulting in a slower bootstrap overall. I believe this > could be much alleviated by allowing us to cache compiled bytecode to disk > (Scripturian does this for Rhino), but I've been told that this feature won't > be available for Nashorn. So, every bootstrap involves compiling the > JavaScript all over again, and it's not fast. > > So, actually for the one area in the software stack where I hoped Nashorn's > performance would shine--bootstrapping--I'm not seeing the benefits yet. > > On 10/14/2013 08:48 PM, Marcus Lagergren wrote: >> Nice one, Tal! Everything works and you are happy with behavior? Faster than >> Rhino? (we are doing some additional performance work right now) >> >> /M >
