[prev] [thread] [next] [lurker] [Date index for 2007/01/28]
Martin Ebourne wrote: > On Sun, 2007-01-28 at 10:04 +0200, Yossi Kreinin wrote: > >>I don't like throw/catch in C++ because it slows down the entire body of code > > > What are you talking about? > > There is no reason for there to be any performance impact at all on C++ > code which handles exceptions right up until the point where an > exception is handled. Of course, there's no slowdown there either 'cause > otherwise you wouldn't be handling an exception. > I'll give 2 examples of C++ platforms: the Green Hills C++ toolchain, and the LLVM toolchain - both designed with optimization as one of the primary goals. Green Hills produces much more code by default than if you ask it to disable exceptions. I couldn't convince it to emit reasonable code with exceptions enabled. LLVM has 2 instructions in it's IR: call (which is not exception safe) and invoke (which will set up things for stack unwinding). Why do they need 2 instructions if invoke can be implemented as fast as unwind? I rarely look at gcc assembly, but I remember it saving things too. How can a C++ function, no matter if it has try/catch statements or not, be exception safe without saving a pointer to the bulk of code (destructor invokations) to call upon stack unwinding? How can you save things at 0 cycles? By "exceptions don't slow things down", do you mean "a C++ program which never mentions the words try/catch/throw runs as slowly as one that does mention them" (I think this is true and I don't like it) or "a true C++ program - compiled with exception support - is as fast as a C program or a program in a C++ dialect lacking exceptions at the compiler level" (I wonder how that works)? Note: of course I might be wrong and I really want to know the answer to these questions.There's stuff above here
Generated at 23:01 on 06 Feb 2007 by mariachi 0.52