2014-09-12 17 views
9

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

Engine performance compared

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; enter image description here

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.

+0

Rhino w języku Java 1.8 może być odkrywcze. –

+0

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

+0

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

Odpowiedz

1

na Java 1.8, można użyć Rhino poprzez javax.script API stosując tę ​​zależność Maven i prosząc silnik rhino:

<dependency> 
     <groupId>de.christophkraemer</groupId> 
     <artifactId>rhino-script-engine</artifactId> 
     <version>1.1.1</version> 
    </dependency> 

Strona główna tutaj: https://github.com/cevou/rhino-script-engine

binaria: here

Jeśli chcesz najnowszą wersję Rhino, możesz ją zastąpić, dodając coś takiego:

<dependency> 
     <groupId>org.mozilla</groupId> 
     <artifactId>rhino</artifactId> 
     <version>${rhinoVersion}</version> 
    </dependency> 

Binaries: here

Nawiasem mówiąc, jeśli chcesz używać uzyskać najnowszy Rhino na Java 1.7 poprzez javax.script, należy zwrócić się do nazwy silnika rhino17R5 lub może przypadkowo dostać wystąpienie starego Rhino który jest częścią JRE. Dokładna nazwa silnika wymagana jest w zależności od wersji rhino-script-engine. W wersji 1.1.1 jest to rhino17R5.

+0

Dzięki. (nie jestem zaznajomiony z mavenem) Nie jestem pewien, ale jeśli twój nosorożca jest tej samej wersji, które można zbudować za pomocą tego artykułu: https://wiki.openjdk.java.net/display/Nashorn/Using+Rhino + JSR-223 + silnik + z + JDK8 Wtedy ten interpreter jest rzeczywiście nieco wolniejszy niż ten wbudowany w java7. Może wiesz dlaczego? – Houtman

+0

Myślę, że ten jest wzięty bezpośrednio z OpenJDK (prawdopodobnie 7), ponieważ jest to wyjątek GPL + Classpath. Myślę, że byłaby to znacznie nowsza implementacja niż ta, o której wspomniałeś. – seanf

+0

Domyślny poziom optymalizacji Rhino mógł się zmienić pomiędzy starszą implementacją "ScriptEngine" dla Rhino i nowszą. – seanf