Short short = new Short(1);
The other two have to do ASCII-to-numeric conversions. The constructor does a fast-path call to the parseShort() code, I think (except when it does something even cleverer).
However, once again we live in the age of smart compilation, so it's not a guarantee that one way is faster than another. If I'm not confusing
Java with one of the C compilers I've worked with, the optimizer is likely to crunch that down into a constant reference (since Short is immutable), and that specifically, commonly-used constants like 0 and 1 may have further magic applied to them so that when you reference them in code, no actual object may be needed at all. If it can be deduced safely.
I really very strongly discourage micro-optimizations. I started out in an era when you could look at code and tell exactly byte-for-byte what the compiler would produce. Back then, worrying about this sort of thing had some merit. That's because back then, we were impressed when they upgraded our mainframe to a full megabyte of RAM.
However, compiler writers have gotten more and more ambitious over the years to the point that you're no longer certain what will be produced, and even a 1-line change in the middle of a module can cause everything to be optimized in an entirely different way. For example, if you used a Short(1) and added a call to hash() on it, the compiler could no longer dispense with an actual Short object, since a "virtual" Short such as the optimizer could produce wouldn't have a hash value. That would force the optimizer to work with a concrete implementation of Short(1).
Because of this, I don't code clever at the micro-level. The compiler designers did studies based on everyday usage and adjusted their optimizers to recognize and optimize these common optimizable usages. If I confuse them by coding "efficient" constructs based on a brute-force implementation, I can actually produce
less efficient code than someone dumber than myself would.
But in the end, there's still no substitute for measurement, and
you should always strive for the most improvement for the least amount of work. There's always more work. The hard part is getting someone to pay for it. That, and staying interested in the project.
