32 ms·
Even if you're right. The issue with coding to optimizations is that it's really, really brittle. You change the position of a variable and suddenly your applic
by iofj 11y ago
Even if you're right. The issue with coding to optimizations is that it's really, really brittle. You change the position of a variable and suddenly your application runs 10x slower.
Why ? Because it just went from O(N) with no allocations to O(N^2) because it has to constantly extend and walk a list (the free memory list, which is lower bounded by the number of iterations of the loop) on every iteration of the loop (malloc is O(N), so calling malloc in a loop automatically increases it's complexity, and compilers change stack allocations into mallocs due to optimizations).
I've seen this happen many times. And then, after 2 weeks of searching you find the cause : someone changed 3 * i into i * 3 in a method which caused autoboxing to suddenly actually occur.
Counting on compiler optimizations to save your ass is incredibly, incredibly brittle.
- pjmlp 11y ago> Even if you're right. I can provide some presentations from Java Language Summit > Counting on compiler optimizations to save your ass is incredibly, incredibly brittle. I agree. Ada, Delphi, Modula-3, Oberon or Eiffel could have been in Java's place with the right stewardship, but sadly it wasn't it. I also don't see it getting replaced anytime soon, hence why I welcome the idea of eventually getting value types and proper AOT on the reference JDK while keeping the huge set of libraries that we have available. In any case, I am both a language geek and a polyglot developer, so I have fun discussing this kind of subjects not being language zealot.