|
|
|
| Authored by: Anonymous on Wednesday, April 18 2012 @ 01:09 PM EDT |
If one is familiar with the optimiser within the compiler/interpreter, one can
try to code in such a way that will take better advantage of it. However, as
optimisers and hardware improves, the extra effort shown in Sun/Oracle's code
may not longer be an advantage (sometimes it could become a disadvantage). At
one point in time these optimisations were/are probably significant though.[ Reply to This | Parent | # ]
|
| |
| Authored by: bugstomper on Wednesday, April 18 2012 @ 02:52 PM EDT |
The person who wrote the code would have been justified in assuming that it was
going to run on Sun's Java VM. If it was any less efficient on a different Java
VM, well it just makes Sun look that much better.
On the other hand, I do think that it looks like code written by a more junior
level of programmer foolishly trying to micro-optimize. When writing a method
that is for general use by millions of people there is no way without a huge
amount of research that can only come later to know things like the relative
number of times that String.compareTo is called on strings of the same length vs
different length, there is no predicting how the VM architecture will change,
what will be done with JIT compilers and architectures that convert some VM
object code to native code on the fly, what the tradeoffs will be on memory
usage vs performance.
With all that, the right way to code is to keep it compact and simple, aiming to
get your performance improvements by improving the algorithm.
[ Reply to This | Parent | # ]
|
|
|
|
|
