ScottHutchinson / EnumDecodeConsole

Minimal, Complete, and Verifiable example
0 stars 0 forks source link

The v141 compiler is much slower #1

Open ScottHutchinson opened 5 years ago

ScottHutchinson commented 5 years ago

All testing is for the Release (x86) configuration.

The master branch targets the v140 compiler. Retargeting to the v141 compiler make the rebuild much slower:

v140 compiler:

1> Elapsed Time: 45.560 sec 1> Total Compilation Time: 98.673 sec 1> Efficiency: 216.6% 1> Average time per function: 0.038 sec 1> Anomalistic Compile Times: 1 1> ??__Eg_decodeFunctions@v57@@YAXXZ: 27.774 sec, 10002 instrs

v141 compiler:

1> Elapsed Time: 114.270 sec 1> Total Compilation Time: 130.198 sec 1> Average time per function: 0.051 sec 1> Anomalistic Compile Times: 1 1> ??__Eg_decodeFunctions@v57@@YAXXZ: 108.635 sec, 72457 instrs

ScottHutchinson commented 5 years ago

I have isolated the performance problem down to the lines below. Comment out that line, and the build time drops from 90+ seconds to < 1 second.

std::pair<enum_class_name, pfnEnumDecode> g_decodeFunctions[] { { "ACTIVATION_TYPE0", nullptr }, { "ACTIVATION_TYPE1", nullptr }, ... { "ACTIVATION_TYPE1999", nullptr } };

ScottHutchinson commented 5 years ago

The workarounds branch of this repo includes two workarounds that effectively fix the problem:

  1. Redefining the enum_class_name alias as const char* instead of std::string.
  2. Add constexpr to g_decodeFunctions.

Fortunately, both these changes should be very easy to implement, and should have no negative effect on functionality or run-time performance.

The combined effect of these two changes is to drop the elapsed build time from ~90 seconds to ~5.4 seconds! With these changes, instead of being slower, the v141 compiler might even be 2-3 times faster than the v140 compiler.

ScottHutchinson commented 5 years ago

Unfortunately, using char* instead of std::string as a key for an std::unordered_map turns out to be non-trivial, if not a bad idea altogether. So this workaround might not be feasible.

I have also noticed slow compile times for any of the sDecode_[enumclassnamehere] functions with a large number of enumerators (and corresponding switch cases). A few of these functions have thousands of cases. Each case assigns a return value to a std::string like this: sRtn = "Deactivation"; break;

Example:

3> ?sDecode_Message_Id_t@v090700@@YA?BV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@H@Z: 1.826 sec, 30754 instrs