On 9/30/07, Emil Dotchevski <emil@revergestudios.com> wrote:
[snip]
In the particular case of Boost Exception, any speed overhead it adds should be compared to the overhead of throwing an exception. You have stack unwinding and destructor calls, etc. anyway. I don't think that optimizing Boost Exception for speed makes any sense.
I agree with this.
Optimizing the memory allocations made by Boost Exception when info is added to exception objects can not be dismissed as easily, but I would not call those allocations unnecessary. :)
But I believe that we should be able to allow not making any heap allocation within some measure. Using a custom pre-allocated heap should make *some* information to be held without any allocation. Types that use heap on construction/copy-construction we don't have much choice anyway. It could be disabled/enabled and the size could be customized.
Consider that all of these allocations happen immediately before or during stack unwinding, and at that time the rest of the code doesn't usually allocate memory. When the exception is finally handled, all this memory is reclaimed, and assuming that no other memory was allocated during the stack unwinding, we don't get fragmentation either.
My biggest concern is bad_alloc being thrown and the exception being replaced. It might not be as bad for most cases, but may be critical in others. [snip]
Emil Dotchevski
-- Felipe Magno de Almeida