1) It does work ok on libs eg .NET v1 had only exceptions , people
complained the most about certain functions , v2 added a few methods
where there were perfomance issues namely int.parse . I think this works in
practice because in most cases where you do this its validation and these
libs tend to be under your control .
2) Yes i hate the use of out ... Again for validation though its less of an
issue since validate does not return.
3) Agree.
I dont think the unwinding is the performance issue in C# its the actual
throw you can do the throw in a tight loop with a deep stack and it is
still slow.. eg throw does the following , copy the stack to an exception
object then change all the addresses to string ( which probably does some
reflection) .
There may be an optomized case here.. you are normally only after a single
fast exception and the "fast" excpetion you need are pretty rare . so you
can run a lambda when an exception occurs in a finally block instead of
throw and treat it as uncaught.
eg something like
bool fails = true;
using GlobalHandler (typeof(ArgumentException) , x=> fails = false)
{
// do calls
}
and the compiles checks if a global handler is loaded and runs that instead
of throw ... Still pretty ugly IMHO..
Or better yet just return back to the handler but dont copy the stack and
build the full information to the object if there is a GlobalHandler in
scope..
Another option maybe to do a small creation of an Exception ( eg access/
copy the address to method name map table and stack but dont do anything
) and work it all out when the excepetion is uncaught. You really do not
want to loose the stack with string methods ..for most uncaught exceptions .
Any form of handling is going to be at least 10-100 * slower than an if
condition which returns a value ( due to cache hits and exceptions
preventing optomizations) , so you will need to do that aynway when you
need the highest perfromance , How much code needs that level of
performance on a fail condition ? Anything else is premature opt.. IMHO.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
