C++ Exception Speed?

In my experience exceptions don't provide a noticable speed drop, unwinding the stack is slow, but that only should happen when an exception is thrown and therefore speed really isn't a concern. Just avoid the trap of using an exception to handle non-exceptional cases and you'll be fine.

Also, I'm fairly sure (but not 100%) that RTTI isn't necessary for typed exceptions.

Quote:

Original post by cozman In my experience exceptions don't provide a noticable speed drop, unwinding the stack is slow, but that only should happen when an exception is thrown and therefore speed really isn't a concern.

Yeah, well if they don't slow things down when they aren't thrown it's fine. But this is for a virtual machine, so I can't really tolerate any slowdown during runtime.

Quote:

Just avoid the trap of using an exception to handle non-exceptional cases and you'll be fine.

That won't be a problem. I will be using them to handle critical execution errors, and as soon as one happens, execution stops.

Quote:

Also, I'm fairly sure (but not 100%) that RTTI isn't necessary for typed exceptions.

I'm hoping so.

A try/catch block will cost a single thread-local store on MSVC, and may cost nothing on some other compilers.

A throw will basically cost an arm and a leg. Don't consider using throw as part of normal program execution.

Last time researched this, in MSVC code compiled for x86 every time you create a destructable object on the stack it inserts one extra instruction to help itself unwind. This can be mitigated if the compiler can prove to itself that it won't have to unwind these objects due to an exception. I also understand that a try/catch block will disable some sorts of optimizations within that block but I don't know what precisely.

For RISC versions of MSVC the one instruction per-destructable object is eliminated. I don't know if native x64 code uses the x86 or the RISC model for this sort of thing.

Results for other compilers may, and probably will, be different. The may even differ between versions of MSVC.

The takeaway for me is that as long as you don't have try/catch every 5 lines and you don't use destructable objects in inner loops where the compiler might have to unwind an exception, overhead for exception-based code is slim to none and in general less than it's error-code-based equivalent. Actually throwing an exception will be slow but that's not usually relevant because you probably don't care about perf anymore once exceptions start happening.

Quote:

Original post by hplus0603 A try/catch block will cost a single thread-local store on MSVC, and may cost nothing on some other compilers.

How could you implement it such that it costs nothing? I've heard it said before that this is done by some compilers, but can't really imagine how.

A try/catch is significantly cheaper in code space, execution space, and bug space than writing in all the if(success) blah(); around every single function that might throw. It also cleans up your designs since you can use return values instead of archaic return values enumerated in some header file.

If that's what you want to do, then that's what you want to do and there's not a very good way to hack around it.

Well, regarding exception handling, I remember some time ago being stuck with implementing it (and *gulp* classes) in the most coder-friendly way under a C89 *double gulp* compiler. This was THE only moment in my entire coding life when C's goto was actually useful (still evil, though). If you're interested I can dig you up some code/info. PM me if you need anything.