Ok
try{
    mySuperHeavyMethod()
}catch(){}

runs 10 times slower that without try/catch...
why :)

2016-04-17 14:36 GMT+02:00 Serega Sheypak <serega.sheypak@gmail.com>:
ok, I see weird results.
I've wrote a test
https://gist.github.com/seregasheypak/d59997dd2d2dfbf82e310b16398239ca

Here are metrics for method named "play"

TriggerPlayer.play-trigger

             count = 83043

         mean rate = 395.52 calls/second

     1-minute rate = 555.30 calls/second

     5-minute rate = 217.78 calls/second

    15-minute rate = 82.92 calls/second

               min = 0.29 milliseconds

               max = 12.98 milliseconds

              mean = 1.59 milliseconds

            stddev = 1.08 milliseconds

            median = 1.39 milliseconds

              75% <= 2.46 milliseconds

              95% <= 3.14 milliseconds

              98% <= 3.44 milliseconds

              99% <= 3.76 milliseconds

            99.9% <= 12.19 milliseconds


Here are metrics for method named "executeHere"

    count = 81927

         mean rate = 503.31 calls/second

     1-minute rate = 587.41 calls/second

     5-minute rate = 221.08 calls/second

    15-minute rate = 83.42 calls/second

               min = 0.06 milliseconds

               max = 0.47 milliseconds

              mean = 0.08 milliseconds

            stddev = 0.03 milliseconds

            median = 0.08 milliseconds

              75% <= 0.09 milliseconds

              95% <= 0.13 milliseconds

              98% <= 0.16 milliseconds

              99% <= 0.17 milliseconds

            99.9% <= 0.44 milliseconds


"executeHere" faster in 40 times (acrroding to 99th percentile).

I just copy-pasted body of method directly to test...

What does it mean, why it works faster?


2016-04-16 21:52 GMT+02:00 Serega Sheypak <serega.sheypak@gmail.com>:
> Firstly sorry for not answering so fast. I have not so much spare time these days :( And your question requires some thought
No problem, I really happy to get any input from community members side.
if I now assume this will start 1000 threads, each with its own cache, then you get 20k compilations, 
It goes a bit different way. I'll explain how does my installation works.
Storm starts 4 JVM per node. Each JVM has 5 threads to run my code.
Each thread has it's own script factory.
Thread that runs code lives forever (until you kill it or apocalypses happens. Storm can restart thread in case of failure)

> Doing all that unreflection in the indy part and creating those MethodHandles always takes a little time.
It happens only right, correct?
I don't have thousands of threads. There are dozens of them.

>Is it somehow possible to get a small running program showing the problem?
Hm... I'll try to extract it.

2016-04-16 13:27 GMT+02:00 Jochen Theodorou <blackdrag@gmx.org>:
Firstly sorry for not answering so fast. I have not so much spare time these days :( And your question requires some thought

On 11.04.2016 12:58, Serega Sheypak wrote:
[...]
*>do you reuse the scripts, or do you make a new script each time?*
I suppose I do reuse, please have a look at "ScriptFactory"

*Hi, here is naive caching factory:*
https://gist.github.com/seregasheypak/2d7f5a16fa31018c8212754c8e94f9a4

*>To give an advice I have to understand your setup better first*
I run http://storm.apache.org/ topology.
If you are not familiar with it, assume I have a running thread-safe
java application. Java application keeps 1000 User objects and 20
GroovyScripts in memory.
I run 1000 (users) *20 (script: def evaluateExpression(Map context))
executions each second.
If script for User object returns true, I do something special.

I try to cache script instances (see my gist).
User object is just a bean with some logic incapsulated.

if I now assume this will start 1000 threads, each with its own cache, then you get 20k compilations, as well as 20k first time executions. Doing all that unreflection in the indy part and creating those MethodHandles always takes a little time. So it might very well be, that this is the problem, but not sure what we could do then.

Is it somehow possible to get a small running program showing the problem? Then I could check myseld what really happens. JVisualVM helps a bit, but is imho no proper replacement for a real profiler.

bye Jochen