On Tue, Aug 13, 2013 at 1:27 PM, David Jeske <[email protected]> wrote:
> On Mon, Aug 12, 2013 at 1:35 AM, Bennie Kloosteman <[email protected]>wrote: > >> The work on .NET on a throw is clear >> >> a) Create a new Exception object ( there is your 10* cost already + >> branch miss , cache misses from the following etc ) >> b) copy methods from the stack to Exception object ( or whole stack ) >> c) load / copy map of address to method name.* change stack to strings >> now ( or in global handler) >> d) unwind stack till a catch handler is found >> > > Why would you need to do "c" during the throw? It seems like you can > easily do this after. > Exactly the point .. Depends a lot on the architecture... If your mapping changes eg by a dll or assembly unloading by the time you hit a global handler you cant do the lookup , also in .NET at least the debugger will break at the line when your code throws an exception and it has a full stack... The runtime which does this needs to get invoked to do that.. Defering it till the handler is obvious and i cant imagine the people who implemented it are so stupid to overlook it , doing this would have been a lot easier than adding tryparse in v2 of .NET . Maybe this cost is trivial compared to the stack copy . > Also, "b" could be done incrementally as the stack is unwound, preventing > a full stack walk in the case the exception is caught near the throw. > (though certainly at some cost) > Speaking of unwinding you can make this much faster if yoru prepared to ware a small cost ..when exceptions are not thrown. > Return values are fast. This is my criteria a,b,c. >> > > >> Yes, though I see no reason why this should not be true for exception >> handlers when the Liskov implementation technique is used. > > I can not see anyway that an exception mechanism that even if it produces no stack as an option and that creates an object to communicate what type of exception can be faster than say 10* slower for simple validation ( though for IO exceptions its obviously neg. ) . You may be able to get to 2-4* speed penalty for failed exception compared to return if all the following are true - An object is not created eg FastException : NoStackException is a static and when you use these exceptions for throw , the runtime just returns the static instance ( no inheritance , this can only work for a few hard coded types ) - You do not store a stack copy - You can unroll back to the handler fast . eg no deep unwinds Even more what you can do is heavily dependent on the runtime. Though it may be possible depending ont practical factors , Im still not convinced its worth it compared to a few cases of tryparse() - better returns in other areas eg NAT numbers , GC elimination / regions , native SIMD support and structures that woirk writh it eg scope for preserving YMM registers etc etc . Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
