Paul Clapham wrote:Or to convert that to the cost of a single call:
Or to put it another way, you're saving 0.8 microseconds by creating a new Throwable object. That doesn't seem like a savings I would be actively seeking, since presumably in real life you wouldn't be doing this process millions of times anyway. (Right?) However you haven't included the cost of having that Throwable object garbage-collected, so your savings are less than 0.8 microseconds per call and possibly even negative.
Joanne
Koen Aerts wrote:The differences are probably negligible enough to be ignored. I just like to understand why things behave the way they do. For instance I had found that the String compareTo method is slighty faster than the equals method, however the equalsIgnoreCase method is significantly slower than equals.
Campbell Ritchie wrote:You ought to use the nanoseconds method of the System class. And you will find that performance varies considerably on repeated runs.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
See, told you so.Earlier, I wrote: . . . you will find that performance varies considerably on repeated runs.
Jesper de Jong wrote:
Koen Aerts wrote:The differences are probably negligible enough to be ignored. I just like to understand why things behave the way they do. For instance I had found that the String compareTo method is slighty faster than the equals method, however the equalsIgnoreCase method is significantly slower than equals.
Micro-benchmarking is very difficult to do correctly on the JVM.
SCJP
Visit my download page
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |