exception handling costs 50% performance?

[Jochen Theodorou]

Hi all,

I still have to figure out when exactly I need that, but currently I
have an catchException on each resulting handle for the call site. of
course this is not good by itself, but I wonder if other have comparable
numbers.. According to my tests I see a 50% performance decrease if I
use the exception handler compared to when not.

Now I thought this is something the JIT would be able to optimize away
mostly. At least in Java code this normally has no such big impact. Can
somebody confirm that? Maybe even explain why that is so?

bye Jochen

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org

[John Rose]

On Feb 10, 2012, at 4:52 AM, Jochen Theodorou wrote:

I still have to figure out when exactly I need that, but currently I have an catchException on each resulting handle for the call site. of course this is not good by itself, but I wonder if other have comparable numbers.. According to my tests I see a 50% performance decrease if I use the exception handler compared to when not.

Now I thought this is something the JIT would be able to optimize away mostly. At least in Java code this normally has no such big impact. Can somebody confirm that? Maybe even explain why that is so?

I would guess that there is an inlining failure for MethodHandleImpl$GuardWithCatch.invoke_L1 or similar.  Can't tell without a trace of inlining decisions.

To investigate, I would make a microbenchmark that demonstrates the performance differential, and then run with +LogCompilation, etc.

There may also be boxing overheads, since the very special invokers used by GuardWithCatch are not fully signature-polymorphic.

-- John