Constructs a newly allocated Short object that represents the short value indicated by the String parameter. The string is converted to a short value in exactly the manner used by the parseShort method for radix 10.
Always remember: "premature optimization is a root of all evils" All these things are in most of cases insignificant when it comes to the performance of an entire application. [ October 23, 2008: Message edited by: Nitesh Kant ]
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.
Customer surveys are for companies who didn't pay proper attention to begin with.