I cannot attach our complete analysis, but here is the response from Camunda:
Given the characteristics of Nashorn’s usage within Camunda, we would expect it to run more slowly than both “native” Java code and - potentially - other scripting engines as well. This is because the scripting engine isn’t cached and because scripts aren’t compiled and reused. The former - the fact that it isn’t cached - is due to the fact that Nashorn can’t be shared between multiple threads (a characteristic of the scripting engine itself), and the latter is due to incompatibilities with some of the functionality that we need to provide in our scripts.
Our recommendation to you is first to utilize “native” Java code in situations where performance is important. If you must use scripts, please use Groovy; as you’ve noted yourself, it runs faster than does JavaScript within Camunda.
If you’re looking to support another (more modern?) language that can be used within Camunda process applications, you may want to consider Kotlin. While Kotlin can be used as a JSR-223 scripting language, which wouldn’t be supported by Camunda, you can also write Kotlin and compile it down to Java class files, which would obviously work in Camunda just like class files compiled from Java source.
Below are some additional links to other comments:
• The performance impact of scripting in processes
• Major Performance Issues with Java 8 ScriptEngine Compared to Java 7