Exception throwing on Windows x64 is 8,000 CPU cycles in Visual C++ and 20,000 in clang, but grows to 1,800,000 when a debugger is attached to the process.
-
-
Show this thread
-
This cost is mind-boggling for what is essentially a goto-with-destructors. In the process of adopting the “zero cost exceptions” fallacy, modern platforms created a catastrophic performance cliff that makes the feature unusable in real software.
Show this thread -
And it’s not just C++. Other languages build their exception models on top of C++ exceptions and the operating system level plumbing (why should the OS have anything to do with this?) so, for example, JavaScript exceptions are also impractically expensive.
Show this thread
End of conversation
New conversation -
-
-
I remember that from win32 on x86, where exceptions seemed reasonably fast. On x64, there is no trace of exception tracking in mainline code, but some horrible handler that digs through the executable file to find tables of exception handlers.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
I toyed with a new C-like language that supports the "try/catch" mechanism simply by passing in a second Return Address for the fail case so that when a failable function fails, it will return to the catch block of its caller without the need for the caller to check return value.
-
I think that’s exactly what’s needed. Herb Sutter has been developing a similar proposal for C++. In the case of C++, the compiler has to generate a stub of code for all functions that runs local destructors and jumps to the parent handler.
End of conversation
New conversation -
-
-
Over Christmas it was clock cycles on garbage collection, this post on exceptions. Both wastes due to non-specific intent with either memory alloc or knowing conditions of a function? Solutions to lower clock cycles is elixir to the symptom and not a solution to the root cause?
-
In this case I’m not writing a specific program that I can optimize, but a library framework for programming with maximum safety and programmer productivity.
- 1 more reply
New conversation -
-
-
Were the non performance intensive functions throwing? Ie, were the gains from avoiding the cost of throwing?
-
They weren’t throwing and a disassembly showed no visible artifacts of exceptions. But turning off the possibility of throwing exceptions gained 15% and just made the assembly code tighter with no clear pattern to the improvements.
- 3 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.