Task #562
closedOptimization of scripts
100%
Description
We found out, that build of scripts takes considerate time. Aim of this ticket is to optimize it.
Related issues
Updated by Filip Měšťánek over 7 years ago
I implemented a cache for scripts. The script is identified by its source code (not to be confused with code). If the script with given source code doesn't exist, it compiles it. If it exists, it returns the compiled script which is only fed with variables. The one thing I need to solve now is thread safety.
It is in branch mestanekf/script-optimization
Updated by Filip Měšťánek over 7 years ago
- Status changed from New to In Progress
Updated by Filip Měšťánek over 7 years ago
As mentioned here http://docs.groovy-lang.org/latest/html/documentation/guide-integrating.html#_sharing_data_between_a_script_and_the_application, Scripts are not thread safe, therefore I solved it by synchronizing the individual script objects.
Updated by Filip Měšťánek over 7 years ago
- Status changed from In Progress to Needs feedback
- Assignee changed from Filip Měšťánek to Ondřej Kopr
Please do a review (or delegate it)
Updated by Marcel Poul over 7 years ago
- Related to Task #561: resave user performance added
Updated by Ondřej Kopr over 7 years ago
I've read some information about build groovy shell, can also be cached - add cache for shell into your branch.
I tested this locally and your changes works. Last week we have discussion with VS about cache in groovy script. VS recommended use for key in cache parameters and script source, as value use direct output from compile script and only return this compiled value. I will test this change on the project.
Some information about shell cache:
https://stackoverflow.com/questions/5323114/using-groovyshell-as-expression-evaluator-engine-or-how-to-reuse-groovyshell
Updated by Ondřej Kopr over 7 years ago
Updated by Filip Měšťánek over 7 years ago
Before you close this task, make sure the shell is thread safe. Because I'm not sure if it is. If not, we would require to synchronize access to it or make it thread local.
Updated by Ondřej Kopr over 7 years ago
Binding isn't thread safe, but GroovyShell is, see http://marc.info/?l=groovy-user&m=113684533028802&w=2 and discussion below https://stackoverflow.com/questions/5323114/using-groovyshell-as-expression-evaluator-engine-or-how-to-reuse-groovyshell
Updated by Ondřej Kopr over 7 years ago
After discussion with RT change key for cache to hashCode from string body.
Commit: https://github.com/bcvsolutions/CzechIdMng/commit/ff4a4df77abfee73fb61774f03ac73dc5b2a2599
Updated by Ondřej Kopr over 7 years ago
- Status changed from Needs feedback to Resolved
- % Done changed from 0 to 100
Merged into develop
Updated by Filip Měšťánek over 7 years ago
I just hope, we won't run into any collision in the future, because that would be really nasty behavior :)
Updated by Radek Tomiška over 7 years ago
I agree, idea with hashCode as key is not good, because uniqueness is not guaranteed and script code is useless too (for inline scripts), so using string body as key will be safer (but much larger).
Updated by Ondřej Kopr over 7 years ago
After discussion, i have returned all the changes back. hashCode for string it may not be unique, and GroovyShell is thread safe but im not completely sure.
commit: https://github.com/bcvsolutions/CzechIdMng/commit/d4720fe591f38c0ffb6e8d81b962c6c52be5d024