Tracker for Visual Studio compiler bug affecting units about units

[xiangfan-ms]

FYI, I wrote a blog post on various ways to improve the compile time.
The one I suggested above (way 2 in the blog post) actually changes the semantics because in this library 'nameSingular' is a typedef, not a real type. And ADL won't find namespaceName (the real type is in the parent namespace 'units').
However, way 1 and way 3 should still be applicable. Way 3 is probably the best choice.

[nholthaus]

Microsoft is still investigating, but recommend compiling with the option /permissive-, which improves compile time by ~40%.

[nholthaus]

It appears that the code in the library introduces O(n^2) behavior.
In particular:
inline std::ostream& operator<<(std::ostream& os, const namespaceName::nameSingular ## _t& obj) { os << obj() << " "#abbreviation; return os; };
This pollutes the global namespace and will slowdown all calls to 'operator<<'.
The header adds several hundred overloads of operator<< to the global namespace and the compiler has to do overload resolution on each of them because of 'os << ...' in the function definition, the time complexity is O(n^2).
It is suggested to use the following instead (which should benefit all compilers):
namespace namespaceName {
inline std::ostream& operator<<(std::ostream& os, const nameSingular ## _t& obj) { os << obj() << " "#abbreviation; return os; };
}
Regarding why GCC is faster, it is likely related to the fact that VC keeps the default argument of template parameter as token stream and has to re-parse it every time we specialize a function. The function template called in the repro is the ctor in unit_t:
template<class Ty, class = typename std::enable_if<traits::is_scalar_unit::value && std::is_arithmetic::value>::type>
inline unit_t(Ty value) : nls(value) {};
We need to specialize it during the overload resolution of 'operator <<' to see whether the argument can be converted to 'namespaceName::nameSingular' (which is the specialization of unit_t).
The more memory usage is likely related to the decorated name which is larger than the one from other compilers.

[mwu-tow]

Hi, author of the linked bug report here.
I just tested the latest v2.3.x branch ( ff94725 ) and the compile times are greatly improved for MSVC (about 5s down from 22s). And not only — my tests for g++ also showed ~2x improvement.

Thank you for acting so quickly on the issue!

[nholthaus]

Well, you made it easy by getting Microsoft to do all the hard work ;)

…

On Feb 24, 2017 8:08 PM, "Michał Wawrzyniec Urbańczyk" < ***@***.***> wrote: Hi, author of the linked bug report here. I just tested the latest v2.3.x branch ( ff94725 <ff94725> ) and the compile times are greatly improved for MSVC (about 5s down from 22s). And not only — my tests for g++ also showed ~2x improvement. Thank you for acting so quickly on the issue! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ2HH9IUMsrWPQhmECznlfA6Z0-rFM0lks5rf38cgaJpZM4L4kOF> .