Reflect - Calling the same method over and over to be quicker

[davsclaus]

Expected behavior and actual behavior:

This is an enhancement request.

In Apache Camel in our new camel-joor component we use jOOR as an expression language in the Camel DSL that allows our end users to use some small scripting code that with the help from jOOR can be pre-compiled to Java. We wrap the end user code into a single class with a single method with the same method signature.

And for runtime we then call that same method over and over again.

I used a profiler (YourKit) and noticed that jOOR spend some time to compute which method to call. And then noticed I was able to get hold of the class type, and with Java reflection I could find the method (that jOOR would also find) and then keep that method reference for reuse and so its much faster.

The "improvement" in the camel-joor is located around this place
https://github.com/apache/camel/blob/master/components/camel-joor/src/main/java/org/apache/camel/language/joor/JoorExpression.java#L89

I wonder if there could be some API in jOOR that allows end users to do something like this, where you can tell jOOR I want a reference to calling a method with this name and these types, and then keep that reference for calling over and over again.

The profiler shows its significant improvement in terms of reduced object allocations etc. I have some screenshots I will paste to this ticket.

Steps to reproduce the problem:

Versions:

• jOOR: 0.9.13
• Java: 11

[davsclaus]

before

[davsclaus]

after

[davsclaus]

From the screenshot before vs after, you can see that before the profiler captured around 70 object allocations per seconds when calling that jOOR method via call.

And on the after screenshot the object allocations is down to 1 allocation per second, then we call the java.lang.reflect.Method directly.

[lukaseder]

Thank you very much for your feature request, @davsclaus. There was a deliberate choice in early jOOR design to not cache java.lang.reflect objects because that's not trivial to get right both in terms of API design and correctness (making sure we allow for unloading classes): #26

However, I like your idea of adding the additional functionality of getting a hold of a Method (or Field), because that means we still don't have to cache anything.

I'll look into this, this week.