为什么 /Gm 是调试配置中的默认选项而不是 /MP？
在我禁用 /Gm 并启用 /MP 后，VS2010 上的构建时间显着缩短。
我很困惑为什么 /Gm 是默认值。我认为/MP更好。
（如果启用/Gm，由于不兼容，/MP 不会激活。激活/Gm 比激活/MP 需要更多时间。）
After I disabled /Gm and enabled /MP, the build time on VS2010 is reduced significantly.
I am confused as to why /Gm is the default. I think /MP is better.
(If /Gm is enabled, /MP is not activated because of incompatibility. Activated /Gm takes more time than Activated /MP.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我立即想到了几个原因：
使用
/MP选项构建时间的改进取决于用户可用的处理器数量。 Visual Studio 团队可能认为（目前）假设每个人都有多个处理器是不合理的。 （请注意，当涉及到像这样的优化时，超线程不一定算作多个处理器。）/MP选项与某些编译器选项和语言功能不兼容。一般来说，默认值应该尝试最大化兼容性，甚至在必要时以牺牲速度为代价。当选择将其设置为默认设置时，“更好”并不是评估的唯一标准。您不必打开手册来了解“D9030”或“C2813”编译器警告的含义以及为什么在 VS2008 上编译得很好的项目在 VS2010 上却无法编译。文档更详细地解释了这些问题，甚至包括一些有关如何确定是否启用
/MP code> 选项是针对个别情况的最佳决定。每当您发现自己必须发布有关是否应启用某项功能的指南时，默认情况下可能不应启用该功能。高级用户（不，这不是矛盾的：并非每个使用 Visual Studio 的人都是高级用户，因为此名称与相关产品相关），您可以自行决定是否要启用此选项。
Off the top of my head, I can think of a couple of reasons:
The improvement in build time with the
/MPoption depends upon the number of processors the user has available. The Visual Studio team probably doesn't think it's reasonable (yet) to assume that everyone has multiple processors. (Note that HyperThreading doesn't necessarily count as multiple processors when it comes to optimizations like this one.)The
/MPoption is incompatible with some compiler options and language features. Generally, defaults should try to maximize compatibility, even at the expense of speed if necessary. That something is "better" is not the only criteria evaluated when choosing to make it a default setting. You shouldn't have to crack open the manual to see what the "D9030" or "C2813" compiler warnings mean and why your project that compiled just fine on VS2008 won't compile on VS2010.The documentation explains these concerns in more detail, and even include some Guidelines on how to determine if enabling the
/MPoption is the best decision for individual cases.Any time that you find yourself having to publish guidelines on whether or not a feature should be enabled, it probably shouldn't be enabled by default. Advanced users (and no, this is not an oxymoron: not everyone that uses Visual Studio is an advanced user because this designation is relative to the product in question) like you can decide for themselves whether or not they want to enable this option.