Exception handling in the same function slows down compilation time at> 2x, why?

I have a project with several thousand lines with a giant main (~ 800 lines).
The file containing the main function is 7.94 seconds to compile.

The code is structured as follows:

 int main(int argc, char *argv[]) { int result = 0; try { /* 800 lines of code here */ } catch (std::invalid_argument const &ex) { std::cerr << ex.what() << std::endl; return EINVAL; } catch (std::runtime_error const &ex) { std::cerr << ex.what() << std::endl; return -1; } return 0; } 

However, when I just change it to

 void run(int argc, char *argv[]) { /* 800 lines of code here */ } int main(int argc, char *argv[]) { int result = 0; try { run(argc, argv); } catch (std::invalid_argument const &ex) { std::cerr << ex.what() << std::endl; return EINVAL; } catch (std::runtime_error const &ex) { std::cerr << ex.what() << std::endl; return -1; } return 0; } 

Compilation time is reduced to 2.48 seconds!

I can say that the exception handling code is the culprit, because when I delete the surrounding try / catch , I get the same compilation time reduction.

Also, if I mark the run function as __forceinline , compilation time increases to 10.02! But if I do this by pulling out try / catch , then it will drop to 3.27 seconds.

But what gives? What exactly should the compiler do becomes much more computationally intensive when the code is directly inside the body of a try block?

Notes:

  • I'm going to RELEASE mode
  • Microsoft Visual C ++ November 2013 CTP Compiler (native x64)
  • Relevant compiler options: /O2 /Gm- /GS /EHsc (removing /EHsc also speeds up compilation)
+6
source share
1 answer

I suspect the difference is due to an additional cleanup code. C ++ objects declared in a function are destroyed when they exit it, so their destruction code is already in the epilogue of the function and (I think) that the unwrapping of the stack - part of the exception handling process - can use this code. If you need to destroy all these objects without leaving the function, an additional destruction code must be created and managed there, which can affect both the build time and the binary size. Can you tell if there is a difference in binary size?

Although, frankly, I am surprised that any impact (time / size) is measurable. Are 800 lines extremely rich in C ++ object creation? (possibly indirectly)

+1
source

Source: https://habr.com/ru/post/972543/


All Articles