harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Hindess" <mark.hind...@googlemail.com>
Subject Re: More helpful error messages
Date Sun, 26 Mar 2006 20:19:16 GMT
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 <geir@pobox.com> 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 <mark.hindess@googlemail.com>
IBM Java Technology Centre, UK.

Mime
View raw message