Tony, We will keep this general issue open as https://bugs.openjdk.java.net/browse/JDK-8160103 and revisit later on.
— Jim > On Jun 21, 2016, at 11:41 PM, Tony Zakula <tonyzak...@gmail.com> wrote: > > Thank you for looking into this. Much appreciated. We are working on a > large Nashorn project we hope to share soon. > On Jun 21, 2016 8:33 AM, "Hannes Wallnöfer" <hannes.wallnoe...@oracle.com> > wrote: > >> Unfortunately, there is a problem with invalidation of callsites that >> Sundar brought up in the review thread for the issue I filed. >> >> I’ve thought about it, but there isn’t any easy way to do this without >> giving up significant benefits on the other side. I’m closing the issue as >> „won’t fix“, but I’ll continue thinking about a solution for quicker >> creation of global objects. >> >> Hannes >> >> >>> Am 16.06.2016 um 21:11 schrieb Tony Zakula <tonyzak...@gmail.com>: >>> >>> Thank you Hannes. That would be great. We have tried using clear >> before too. >>> >>> @Axel - Thank you for the stats. Interesting to see that. One thing we >> did was use strict mode and use Immediate Functions. This would keep >> variables going to global scope I think. >>> >>> Thanks, >>> >>> Tony >>> >>> On Wed, Jun 15, 2016 at 8:02 AM, Hannes Wallnöfer < >> hannes.wallnoe...@oracle.com> wrote: >>> I prototyped the proposed change to the clear() method. It seems to work >> well and makes a lot of sense to me, so I filed a bug for it: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8159589 >>> >>> I haven’t discussed this with the other team members yet, so let’s see >> what they think. >>> >>> Hannes >>> >>> >>>> Am 15.06.2016 um 11:24 schrieb Axel Dörfler <ax...@pinc-software.de>: >>>> >>>> Am 14.06.2016 um 22:09 schrieb Tony Zakula: >>>>> Interesting. We use on global context and create a new engine context >>>>> with each run. The initial compile of several scripts is over 100ms, >>>>> but then we see that drop to under 10ms. The context creation seems >> to >>>>> have very little overhead. We have not timed that specifically >> though, >>>>> just total process time. >>>> >>>> In my special use case which was a very short JavaScript that was used >> as Comparator, actual execution time was very short, so the impact of the >> optimizations were pretty obvious. >>>> Sorting about 15000 entries took way over 10 minutes before any >> optimization. IIRC after using a single global engine this dropped to about >> 2 minutes. After also reusing the JS context, it went down to 10 seconds. >>>> >>>> Bye, >>>> Axel. >>>> >>> >>> >> >>
