Agreed. I think the solution in the JIRA I submitted has a reasonable balance of being helpful while not being significantly slower than the original.
-Mark. On 3/26/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > Chris Gray wrote: > > On Sunday 26 March 2006 20:10, Magnusson, Geir wrote: > >> The point was to illustrate having useful information in the message. > >> Optime any way you see fit. > >> > >> That said, given that you are throwing an exception... do we really care? > >> I'm praying that we don't have apis that throw exceptions as a normal > >> result of operation..... > > > > java.lang.ClassLoader loadClass() throws a ClassNotFoundException every > > time a > > classloader delegates to its parent and the parent cannot load the class, > > which is pretty normal. There's probably plenty more than that - just try > > instrumenting a VM to print out all the exceptions thrown in java.lang.* and > > watch them fly by ... > > Yah, I guess I didn't say what I was really thinking about (I was > walking down the street coming from dinner) which was the performance > overhead of throwing an exception was so large anyway... > > I threw together a toy program when I got back to hotel. I called a > method that did a minor amount of work (increment the int arg and return > it). Then I created one that did the same, but then threw an exception. > Then I did one that threw an exception in which string concat was > used. Finally, one that thew an exception in which a StringBuffer was used. > > I found, for 5000000 iterations on a 1.86G Pentium M under WinXP using > Sun's 1.4.2_10 > > C:\dev\eclipse\workspace\playspace\java>java -classpath . SpeedTest > test1 - no exception : 16 millis > test2 - exception, static string: 11859 millis > test3 - exception string concat : 13516 millis > test4 - exception stringbuffert : 14125 millis > > C:\dev\eclipse\workspace\playspace\java>java -classpath . SpeedTest > test1 - no exception : 16 millis > test2 - exception, static string: 11594 millis > test3 - exception string concat : 13328 millis > test4 - exception stringbuffert : 13078 millis > > C:\dev\eclipse\workspace\playspace\java>java -classpath . SpeedTest > test1 - no exception : 16 millis > test2 - exception, static string: 10812 millis > test3 - exception string concat : 13047 millis > test4 - exception stringbuffert : 13016 millis > > > So leaving aside the variance from test run to test run, we're seeing > about 74000% overhead due to the exception, and ~20% overhead on top of > static string for using the string concat. (Yes, that's 74,000%) > > I guess we don't get much benefit of using stringbuffer to replace only > one concat (or the compiler is smart enough to do that itself anyway... > > So to summarize - yes, it's proper to use exceptions, and yes, > performance is crucial, generally speaking, and yes, exceptions are used > for "normal" conditions for code paths (although w/ the number above, I > wonder what the overhead for those 'normal' exceptions are... > > So it's a tradeoff. If the exception happens a lot, I agree - make it > fast. But if not, or if we're in the development phase of a library, > make it helpful. Also, maybe we just tag situations like that so we can > go back when the code is stable and optimize... > > geir > -- Mark Hindess <[EMAIL PROTECTED]> IBM Java Technology Centre, UK.
