jit

The traditional answer to "why is Javascript slower than native code?" is: "Because it's interpreted". The problem with this claim is that interpretation is not a quality of the language itself. As a matter of fact, nowadays most Javascript code is being JITed, still, this isn't even close to native speed. What if we remove the interpretation factor from the equation and make Javascript AOT compiled? Will it then match the performance of native code? If yes, why isn't this widely done over the web*? If no, where is the performance bottleneck now? If the new bottleneck is DOM, what if we

I have a BIG application that I'm trying to optimize. to do so, I'm profiling / benchmarking small elements of it by running them millions of times in a loop, and checking their processing time. obviously Hotspot's JIT is kicking in, and I can actually see when that happens. I like it, I can clearly see things going much faster after the "warm up" period. however, after reaching the fastest execution speed and keeping it for some time, I can see that the speed is then reduced to a less impressive one, and it stays there. what's executed in the loop does not actually change much, so I can

I'm using numba to make some functions containing cycles on numpy arrays. Everything is fine and dandy, I can use jit and I learned how to define the signature. Now I tried using jit on a function with optional arguments, e.g.: from numba import jit import numpy as np @jit(['float64(float64, float64)', 'float64(float64, optional(float))']) def fun(a, b=3): return a + b This works, but if instead of optional(float) I use optional(float64) it doesn't (same thing with int or int64 ). I lost 1 hour trying to figure this syntax out (actually, a friend of mine found this solution by chance because

I've been benchmarking my app and analyzing it with JMC. I've noticed that under load, it performs quite a bit of JIT compiling. If I send a large amount of transactions per second, the compile time spikes. The compile time always grows proportionally with any heavy load test against the app. I've also observed that the Code Cache slowly rises as well. So I decided to raise the Code Cache reserve to 500MB to test. Bad move! Now it's spending even more time performing JIT. Then I explicitly disabled code cache flushing via -XX:-UseCodeCacheFlushing . However, I noticed that the peak Code Cache