JSR233 proposes Compilable interface and many ScriptEngine implement it

I think we should improve this part by doing something like that:
- We could compile script code
- then cache it (which key to use ? add a new property ? use Sampler Name ? use file script name ? use a hash of Script code ?)

I tested this approach:
- It fixes the memory leak issue
- It gives fabulous performance enhancements

But doing so means script code must not contains variables which would forbid caching the compiled code unless we hash script code to see if it changes but this will introduce a performance issue on this hashing.

[reply] [-] Comment 5 Sebb 2012-06-30 08:58:13 UTC

The scripting elements were intended mainly for prototyping and ad-hoc testing; the intention being that the script would often be turned into a Java class if necessary for performance. So performance and memory consumption are not as important as for the Java classes.

That's not to say that improvements aren't useful, but such improvements must not affect backwards compatibility; in particular variables must be supported as before.

The JSR223 test elements support reading the script from a file, and parameters can be passed to the file, so one way to improve performance without affecting compatibility would be to cache the compiled form of a file using the key of file name+modification time.

The same could apply to the ScriptEngineManager: cache that if using a file.

This would guarantee compatibility, and probably not be too difficult to implement, nor be difficult for users to convert their test elements.