Is there a way to tell JVM to optimize my code before processing?

Question

I have a method, which takes much time to execute first time. But after several invocations, it takes about 30 times less time. So, to make my application respond to user interaction faster, I "warm-up" this method (5 times) with some sample data on initialization of application. But this increases app start-up time.
I read, that JVM's can optimize and compile my java code to native, thus speeding things up. I wanted to know - maybe there is some way to explicitly tell JVM that I want this method to be compiled on startup of application?

Answer 1

The JVM does JiT (Just in Time) optimizations at runtime. This means that it can analyze how your code is executing and make optimizations to deliver runtime performance increases. This happens at runtime. If you are seeing the method get faster after a few executions, it is probably because of the JiT optimizations (unless your analysis is flawed and, say, the method gets faster because the data gets simpler). If you analysis is correct, compiling to native might actually hurt you because you will no longer get runtime optimizations.

Can we see the method? You might be able to make it faster without having to worry about how the JVM works. You should isolate exactly where the most costly operations are. You should also verify that this is not some sort of garbage collection issue. i.e. maybe the method is fine, but there is a GC going on that is chewing up time, and when it is done your method runs at acceptable speeds.

Answer 2

the JIT optimizations work so well precisely because they optimize what your code actually does, and not what it could do in different instances.

It's even possible that the JITted code is different on different runs because of different input data. Or even it could be reoptimized more than once when circumstances change.

In other words: without real data, the JVM won't do a good job optimizing code. (i.e. it can only do 'static' optimizations)

But in the end, if you're getting so high improvement (30x is a lot!), it's quite likely that it's either

• not the code but something else (like file or database caches)
• very non-optimal code at the source level. (like some heavy calculations that could go out of tight loops)

EDIT:

After looking at your code, in a big loop on Literas.prepareLiteras(), you're continuously calling path.contains(p) with different points but the same path. SimplePath.contains() creates a bounding shape each time it's called, so you end up creating the same shape again and again. That's a prime example of something that should be pulled out of the inner loop.

I don't think the JIT can optimize that whole method away, but in some extreme cases it might convert the getShape() into something specialized for a single path, and recompile again for the next path. Not a good use of JVM smarts, eh?