Bryce McKinlay writes:
> Andrew Haley wrote:
>
> >The gcc exception processing mechanism is designed to be very fast for
> >the "never thrown" case, but it is slower when exceptions are thrown.
> >I suppose gcj could change to optimize for things like this, but IMO
> >it would not be such a good idea for "reasonable" applications.
> >
> >I'm very tempted to fix getValueOf() so that it does what its
> >specification requires, but that would invalidate the benchmark.
>
> Even HotSpot is slow for thrown exceptions (though not as significantly
> as GCJ), and Sun recommend against using exceptions to signal
> non-exceptional conditions. So in cases like this there is a pretty good
> argument for submitting a fix upstream, since the application will
> perform better on most/all implementations - not just GCJ.
Good idea. I'll try doing that.
> However, its also true that exception performance will continue matter
> in many real-world apps, and anything that can be done to speed up
> throwing in GCJ would be good.
Well, one of the obvious ways to make throwing faster is to compile
libgcj with a frame pointer and use the call chain to capture the
stack trace rather than using the unwinder. That would improve the
performance of this particular benchmark severalfold, but I'm pretty
sure it's a bad thing to do.
I don't know, really. Sure, I care about benchmarks and so do our
users. But ...