Question

As a follow up to this question, is it a good thing that my the top 2 things are still exception handlers? on one hand, its doing a lot of exceptions. on the other, this is in sdl, meaning that its probably as optimized as possible, which means that my other functions are really fast. so…

here’s the top of the profile of the program after running for around 64 seconds, after i did some optimization

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
  8.32      3.39     3.39                             _Unwind_SjLj_Register
  6.77      6.15     2.76                             _Unwind_SjLj_Unregister
  6.28      8.71     2.56  4000006     0.00     0.00  CAST128::setkey(std::string)
  3.73     10.23     1.52                             std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  3.61     11.70     1.47                             __dynamic_cast
  3.56     13.15     1.45 64000080     0.00     0.00  CAST128::F(int&, unsigned int&, unsigned int&, unsigned char&)
  3.26     14.48     1.33                             std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&)
  3.09     15.74     1.26                             std::istreambuf_iterator<char, std::char_traits<char> > std::num_get<char, std::istreambuf_iterator<char, std::char_traits<char> > >::_M_extract_int<unsigned long long>(std::istreambuf_iterator<char, std::char_traits<char> >, std::istreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, std::_Ios_Iostate&, unsigned long long&) const
  2.94     16.94     1.20                             std::string::compare(char const*) const
  2.32     17.89     0.94  4002455     0.00     0.00  unhexlify(std::string)
  2.06     18.73     0.84                             std::string::operator[](unsigned int)
  2.01     19.55     0.82 32037245     0.00     0.00  std::string makehex<int>(int, unsigned int)
  1.94     20.34     0.79                             std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned int)
  1.91     21.11     0.78                             operator new(unsigned int)
  1.87     21.88     0.76                             std::string::append(std::string const&)

cast128 is run 100000 times, which explains explains why it is on top

Answer 1

These are not exception handlers, but rather functions to notify the exception handler of destructors that need to be called if an exception is thrown. For example, consider

for (int i = 0; i < 1000000; ++i) {
    std::string stuff; // or any type with a non-trivial destructor
    function();        // maybe with arguments that depend on "stuff"

    // inline code using "stuff" here
}

Every iteration, the string is created and destroyed, and must be registered and unregistered with the exception handler each time in case function() throws. You may be able to avoid this overhead in various ways, depending on exactly how the object is used:

• If the object (or anything created from it) is not passed to the function, move its definition after the function call
• Declare function (and any functions it calls) inline, so that any exception is thrown from the same stack frame as the object; I believe it won’t be necessary to register the object then, as long as the function actually is inlined
• Make sure function won’t throw an exception, and add a throw() specification to it
• Move the object outside the loop, reinitialising (or calling clear() in my example) if necessary at the start of each iteration (this will also eliminate the overhead of creating and destroying it)