Hacker News new | ask | show | jobs
by lf-non 1851 days ago
I am curious what library was this and what was it doing.

We used spring expression language for dynamic evaluation of (user-defined) expressions in our code and for most cases we could compile and cache the expressions after first usage and invoking them was really fast and close to pure java expressions.

We also had some JVM-python interop which we eventually got rid of (in favor of kotlin) because we were unable to optimize it after a month of effort and it continued to be the biggest bottleneck in the system.

So I am not entirely convinced that there could be real-world usage scenarios that inherently demands so much runtime dynamism that most benefits of JVM optimizations are nullified.

Of course, I'd love to be enlightened otherwise, but rather happy with JVM as of now.

2 comments

There is nothing at the JVM level that would disallow such dynamism. Clojure, JRuby, JPython all can run on the JVM.

Also, if you are looking for interop, then GraalVM might be worth a look — not the better-known AOT part, but the runtime one, which can seamlessly do interop between a number of languages, and it even optimizes between them!

Yes, being possible and being performant are two very different things.

What I intended to convey in my previous comment was that using strategies like pre-compilation (eg. Spring EL) it is possible to get good performance even for dynamic logic not known at runtime.

So I was curious what was so dynamic about this use case that JVM performance drops down to pythonesque level.

I don't want to speculate - maybe there is something that JVM is unable to optimize; maybe it is something weird happening in the library; or maybe python has gotten really better in recent past or this use case was able to benefit from some python lib with native bindings.

Seeing all the dynamic languages running on top of the JVM without any trouble, I doubt the answer should be sought at that level.
It was the Google datastore library maybe 5-7 years ago.