On Wed, Aug 7, 2013 at 6:35 PM, William ML Leslie < [email protected]> wrote:
> Both you and Bennie seem to be saying, effectively: > > "The handler probably knows if it needs a filled-in stack trace or not" > > and you want to be able to communicate that to the raise statement > (which should probably be polymorphic on this condition). > Actually, I was saying that I think the reason we see more expensive throw is because they are preserving stack-frame-info before it's destroyed. I think this might be a harder problem than you're suggesting... The top-level handler definitely wants a stack backtrace, but you don't know whether you're going to hit the top-level handler or not. If the need for a stack-backtrace is statically propagated, a handler in the middle might not want stack info, but it may decide to re-throw the exception, or re-throw a nested-exception -- in which case you'd like the whole stack info to reach the top but it's too late to get it. I need to re-benchmark current runtime throw vs return performance to see where it's at today. Last time I tested, Java throw was 25 times slower than return values, and CLR throw was a stunning 1400-times slower than return values. I don't know what the right solution is. Perhaps there is a compromise where throw is a bit more expensive than return, but still really darn fast.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
