Using Java/C# code in lambda expressions - Compiling to JIT/IL on runtime

[royimi]

Hi,

We've done a lot of load tests and found out that most of our CPU usage is spent on evaluating lambda expressions.
We have 20-30 lambda expressions in each WF, from mapping outputs of APIs, making smart decisions if to terminate the WF and more.

Our original load test showed that we can run around 10-15 WFs per second, this was limited by CPU of server as it reached 90-95% CPU usage.
After just removing 10 lambda expressions we reached 40-45 WFs per second, and our CPU usage went down dramatically to around 70% at peak (and it shows that the bottleneck passed to a different component)

If parsing and evaluating very simple lambda expressions takes so much CPU compared to compiled or semi-compiled code, we've been wondering if it would be possible to just use Java/C# code in our lambda expressions, and have the conductor compile them once on runtime and save the JIT/IL code to be used over and over again instead of re-parsing and re-evaluating the JS on every WF execution.

Is this idea ever came up? any thoughts?

Thanks in advance

Royi Mindel
Senior SE, Payoneer.

[boney9]

Hi @royimi - This is actually a great idea. In fact in our build we are using an optimized version of inline / lambda tasks which for the least part will use some precompiling techniques with a different JS engine (instead of nashorn) and this runs much better. We have actually built this into a GraalVM native build which further optimizes the compute and memory usage.

In our version we are still using Javascript, but it gets compiled to Java and is re-used as long as the script is the same in the subsequent executions.

[royimi]

Hi @boney9! Thanks for the reply, helps to know that others encounter the same issues we do.

Are the changes you guys made OS in some fork we can take inspiration from by any chance?

Starting to think what's the best course of action.

Do you think a PR to conductor's core would be accepted as a new runtime-compilation expression engine?

[aravindanr]

@royimi we do have an open issue #2312 to switch to GraalVM. However, its not on the top of our list.

@boney9 is it possible to contribute your GraalVM implementation?

[boney9]

Hey @aravindanr - the GraalVM we have is still a very custom implementation on top of the pre-release spring-native. I think we should wait until the spring-native gets a full release before this can be contributed as things can be broken often

But @royimi - I think a PR for this can definitely be accepted - if you are trying something out, perhaps that can be the first version to move from Nashorn. Let me know if you want to collaborate on this.

[boney9]

Tagging @jmigueprieto who is looking into the same thing

[boney9]

Also tagging @manan164

[boney9]

@royimi - FYI @manan164 is working on a PR that allows for customizing the scripting engine - #3035