harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: More helpful error messages
Date Mon, 27 Mar 2006 02:47:51 GMT
Chris,

The "Micro performance benchmarking" using Java is danger, because of 
JIT's optimization may "overwhelm any detectable differences in 
underlying performance"[1], so I agree with you that the example 
probably exaggerates effect of exception.

On the other hand, we all know exception throwing does introduce 
considerable performance overhead, at least the required stack frame may 
affect JIT's work(as your analysis), so the example is trustworthy in 
some sense.

[1] http://www-128.ibm.com/developerworks/library/j-perf12053.html

Chris Gray wrote:
> On Sunday 26 March 2006 21:10, Geir Magnusson Jr wrote:
>
>   
>> 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
>>     
>
> This simple example probably exaggerates the effect of the exception - test1 
> is probably so trivial that the JIT compiler probably optimises it to almost 
> nothing, while the other tests require e.g. a stack frame in which the 
> exception can be thrown. It would be interesting to see the results on some 
> other VMs (including gcj). That being said, these numbers do indicate how 
> relying on exceptions for normal flow of execution can seriously damage 
> performance.
>
>   
>> 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...
>>     
>
> String concatenations are translated to StringBuffer (or StringBuilder) 
> operations by the compiler - there is no strcat opcode. If you're building up 
> a string in stages, e.g.
>   String s = "foo:";
>   if (bar) s += "bar";
>   else s += "baz"
>   ...etc. ...
> then it's worth replacing s by a StringBuffer and doing an explicit toString() 
> at the end:
>   StringBuffer sb = new StringBuffer("foo");
>   if (bar) sb.append("bar");
>   else sb.append("baz");
>   ...etc. ...
>   String s = sb.toString();
> because otherwise the compiler generates code to convert the String to a 
> StringBuffer and back at every stage. But if you're just writing
>   "Hello " + name + ", how are you?"
> then you save nothing by converting this to
>   new StringBuffer("Hello ").append(name).append(", how are you?");
> because the generated bytecode is the same.
>
> Chris
>
>   


-- 
Paulex Yang
China Software Development Lab
IBM



Mime
View raw message