2 ms·
>the optimiser decides to recompile the bytecode to improve performance, but the recompiled version actually ends up being slower. I had that happen while deve
by jffhn 5y ago
>the optimiser decides to recompile the bytecode to improve performance, but the recompiled version actually ends up being slower.
I had that happen while developing a fast "exp(double)" implementation: for some reason casting a double into an int can be very slow (at least on some architectures) if the double is not close to int range, so I took care to put each of two (exclusive) occurrences of the statement "int i = (int)foo;" after special cases dealing with huge values, but the JIT reworked the code by factoring them above the special cases, making the code much slower for huge values. My first workaround was to replace one of the "int i = (int)foo;" by "int i = -(int)-foo;", which behaved the same in practice but was not factored out by the JIT.
- lokedhs 5y agoThanks. I'd guess something similar happens here. However, I doubt it's they same case as you, since there are no floating point operations involved here. How's were you able to figure it out? Where should I start looking?
- jffhn 5y agoI didn't use any tool, I just knew these casts could be slow and changed one to avoid a suspected factorization, which just worked, but there are ways to show the code generated by the JIT, cf. https://stackoverflow.com/questions/1503479/how-to-see-jit-compiled-code-in-jvm https://stackoverflow.com/questions/1503479/how-to-see-jit-c... or https://stackoverflow.com/questions/30928786/how-do-i-check-assembly-output-of-java-code https://stackoverflow.com/questions/30928786/how-do-i-check-...