With link-time optimization, MSVC decodes polylines about a quarter slower than a plain Release build. Windows wheels are not built with link-time optimization (only the Linux wheels are, see benchmarks/build_settings.md), so this does not affect anything shipped today. It matters if Windows ever gets link-time optimization, which speeds up loading by about 16% there.
Measured at e66b8a2 with the Catch2 benchmark polyline::decode on 10k points, MSVC 19.51, Release against Release + /GL /LTCG, five alternated rounds on a desktop with background load:
- The medians overlapped because of noise, but in a follow-up the fastest link-time-optimized round was still slower than the fastest plain round: 0.74x at precision 5 and 0.77x at precision 6.
- An earlier comparison, before the encoder change in e66b8a2, showed 0.87x.
- GCC is not affected.
parse_gpx_time is also slightly slower under link-time optimization with MSVC (0.93x, consistent over 13 rounds). On GCC the equivalent slowdown turned out to be an inlining-budget effect (see build_settings.md); whether MSVC's has the same cause is not known.
The encoder had a similar MSVC-only slowdown under link-time optimization, which turned out to be a store-to-load forwarding stall on std::string's inline buffer. That was found by profiling a loop that only calls the function and mapping the samples onto the instructions of both builds. The same approach should work here.
With link-time optimization, MSVC decodes polylines about a quarter slower than a plain Release build. Windows wheels are not built with link-time optimization (only the Linux wheels are, see
benchmarks/build_settings.md), so this does not affect anything shipped today. It matters if Windows ever gets link-time optimization, which speeds up loading by about 16% there.Measured at e66b8a2 with the Catch2 benchmark
polyline::decodeon 10k points, MSVC 19.51, Release against Release +/GL /LTCG, five alternated rounds on a desktop with background load:parse_gpx_timeis also slightly slower under link-time optimization with MSVC (0.93x, consistent over 13 rounds). On GCC the equivalent slowdown turned out to be an inlining-budget effect (seebuild_settings.md); whether MSVC's has the same cause is not known.The encoder had a similar MSVC-only slowdown under link-time optimization, which turned out to be a store-to-load forwarding stall on
std::string's inline buffer. That was found by profiling a loop that only calls the function and mapping the samples onto the instructions of both builds. The same approach should work here.