libcsdbg uses a nice approach creating the stack trace for exceptions.
But our first tests show some major performance issues, about 15 milliseconds per function call on an Intel Xeon E5530 @ 2.4 GHz even when no exception occurs. A first glance at the code shows that it looks like filtering and symbol lookup is done for every call/exit independent of the occurance of exceptions. Is there a reason why you don't postpone this effort to a point where it is really needed (the handling of an exception that actually happened)?
I've no problem with exceptions using a lot more CPU than the normal code (they are by definition exceptions ;-), but for the standard program flow this looks a bit too expensive to me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First of all i need to clarify that libcsdbg is actually a generic stack tracer and stack debugging tool. It not only provides runtime exception stack traces but it also provides real-time thread stack traces generated from any running thread FOR any of the running/stopped/suspended threads. It even can provide dumps of all thread stack traces. Of course it is mostly targeted for debug and not release editions.
That is why i do lookups (to update the current stack of each thread) on any call. Lookups are really lightweight and heavily optimized, although there is place for more optimization.
The filtering and plugin calls, you are right, they ARE heavy. After all filtering was just added (in version 1.28) and it is in a very rough-tough first version. It will be optimized in the future, but it will remain one of the most heavyweight components of the library.
Of course you can compile libcsdbg without all these "exotic" features on. Please take a look at this doc section:
for details on how to exclude filtering all together (after all filtering can be done at compile time, with gcc).
I'd wish you would compile a version of the lib with only the basic needed functionality and re-run your benchmarks, to have a look on how it goes.
To be really sincere, apart from the core features the rest of the library is not optimized for performance. This is going to change on future editions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
libcsdbg uses a nice approach creating the stack trace for exceptions.
But our first tests show some major performance issues, about 15 milliseconds per function call on an Intel Xeon E5530 @ 2.4 GHz even when no exception occurs. A first glance at the code shows that it looks like filtering and symbol lookup is done for every call/exit independent of the occurance of exceptions. Is there a reason why you don't postpone this effort to a point where it is really needed (the handling of an exception that actually happened)?
I've no problem with exceptions using a lot more CPU than the normal code (they are by definition exceptions ;-), but for the standard program flow this looks a bit too expensive to me.
First of all i need to clarify that libcsdbg is actually a generic stack tracer and stack debugging tool. It not only provides runtime exception stack traces but it also provides real-time thread stack traces generated from any running thread FOR any of the running/stopped/suspended threads. It even can provide dumps of all thread stack traces. Of course it is mostly targeted for debug and not release editions.
That is why i do lookups (to update the current stack of each thread) on any call. Lookups are really lightweight and heavily optimized, although there is place for more optimization.
The filtering and plugin calls, you are right, they ARE heavy. After all filtering was just added (in version 1.28) and it is in a very rough-tough first version. It will be optimized in the future, but it will remain one of the most heavyweight components of the library.
Of course you can compile libcsdbg without all these "exotic" features on. Please take a look at this doc section:
http://libcsdbg.sourceforge.net/index.html#sec3_1
for details on how to exclude filtering all together (after all filtering can be done at compile time, with gcc).
I'd wish you would compile a version of the lib with only the basic needed functionality and re-run your benchmarks, to have a look on how it goes.
To be really sincere, apart from the core features the rest of the library is not optimized for performance. This is going to change on future editions.
In version 1.2 massive optimization was introduced. please benchmark