Użyłem Rhino dla komponentu skryptowego wewnątrz grafiki. W projekcie istnieje około 200 małych skryptów działających niezależnie. Natychmiast po uruchomieniu aplikacji skrypty powinny działać z pełną szybkością. Wydajność Rhino była wystarczająca, ale odkąd Oracle radzi migrować do Nashorn, mam do czynienia z dylematem.Czy zalotność startupów Can Nashorn zostanie przezwyciężona?
Poniżej obrazek przedstawiający różnicę obciążenia między Rhino i Nashorn w przybliżeniu 15 000 wywołań skryptów. Początkowa powolność Nashorn to mój największy problem.
Uwaga, wróciłem do JDK 1.8.0. JDK 1.8u5 jest podobna
Mam nadzieję, że obraz jest wyraźny.
To jest zarys jak używam ScriptEngine:
- Używam One skryptowy instancji silnika,
- utworzyć obiekt CompiledScript dla każdego scenariusza,
- SwingWorker wykonuje CompiledScript .eval() raz.
- Co pół sekundy uruchamiane są SwingWorkers.
- Każdy skrypt CompiledScript ma własną instancję SimpleScriptContext, która jest ponownie używana dla każdego wykonania.
Poniżej przedstawiono profil uruchamiania silnika w miarę upływu czasu;
Czy ktoś wie, jak pokonać powolność uruchamiania Nashorn?
UPDATE 15 kwietnia '15
Ran ten sam test z 200 oddzielnych skryptów na Java8u45.
Wydajność jest znacznie lepsza! Działa tak szybko jak Rhino na Java7.
Rhino w języku Java 1.8 może być odkrywcze. –
Dzięki, to byłaby moja ostatnia nadzieja. Przy okazji, czytałem [tutaj] (https://wiki.openjdk.java.net/display/Nashorn/Using+Rhino+JSR-223+engine+z+JDK8), że potrzebuję ręcznie zbudowanego słoika. Każdy pomysł, dlaczego, a może po prostu dla zniechęcenia? – Houtman
Przeczytałem: "Jeśli chcesz zamiast tego uzyskać gotowy kod binarny, możesz pobrać stąd:" - więc nie ma problemu. Jest skompilowany w nie Java 1.8 - więc co z tego. –