blocks|key|174755|text|您是否使用/MP选项(没有文档，必须手动将其输入到处理器选项中)以启用源级并行构建？这将大大加快您的编译速度，而不仅仅是一个更快的硬盘。这方面的收益微乎其微。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|174756|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Are you using the /MP option (undocumented, you have to enter it manually to your processor options) to enable source-level parallel build? That'll speed up your compile much more than just a faster harddisk. Gains from that are marginal.

blocks|key|174707|text|Visual+2005可以并行构建多个项目，默认情况下将在多核计算机上这样做，但取决于您的项目如何相互依赖，它可能无法并行构建它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|174708|如果您的1200个cpp文件位于一个项目中，那么您可能没有使用所有的CPU。如果我没有弄错的话，C6600就是四核CPU.|174709|戴夫|174710|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Visual Studio 2005 can build multiple projects in parallel, and will do so by default on a multi-core machine, but depending on how your projects depend on each other it may be unable to parallel build them.

If your 1200 cpp files are in a single project, you're probably not using all of your CPU. If I'm not mistaken a C6600 is a quad-core CPU.

Dave

blocks|key|174584|text|我认为硬盘读取不是编译过程中的瓶颈。实际上，很少有东西需要从/写到硬盘上。您可能会看到更多的ram或更快的处理器性能的提高。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|174585|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I imagine that hard disk reading was not your bottleneck in compilation. Realistically, few things need to be read/written from/to the hard disk. You would likely see more performance increase from more ram or a faster processor.

blocks|key|298007|text|我会从结果中建议，要么您的hdd延迟速度不是您正在寻找的瓶颈，要么您的项目已经接近于尽可能快地构建。需要审议的其他项目如下：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|298008|limitations)|298009|RAM访问时间(尽管由于总线速度、limitations)|unordered-list-item|298010|
|298011|RAM访问速度和大小、|298012|298013|处理器速度、|298014|298015|、减少后台进程|298016|
)，您可能无法对此做太多工作|298017|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|W|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|X|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|Y|8|@]|9|@]|A|$]]|$1|K|3|H|5|6|7|Z|8|@]|9|@]|A|$]]|$1|L|3|M|5|F|7|10|8|@]|9|@]|A|$]]|$1|N|3|H|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|F|7|12|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

I'd suggest from the results that either your hdd latency speed wasn't the bottleneck you were looking for, or that your project is already close to building as fast as possible. Other items to consider would be:

<ol>
<li>hdd access time (although you may not be able to do much with this due to bus speed limitations)</li>
<li>RAM access speed and size</li>
<li>Processor speed</li>
<li>Reducing background processes</li>
</ol>

blocks|key|174593|text|~6%25的速度增长只是改善你的硬盘驱动器。就像豪勒说的。拿一些更快的内存，和PCU。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|174594|entityMap^0|8|2|U|3|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

~6% increase in speed just from improving your hard drive. Just like Howler said. Grab some faster ram, and PCU.

blocks|key|174689|text|正如许多人已经指出的，您可能没有攻克真正的瓶颈。随机变化的部分(或代码为这件事)，可以说是“低音编码”。您首先确定性能瓶颈，然后更改一些内容。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|174690|Perfmon可以帮助您获得一个很好的概述--如果您是CPU或I/O绑定的，您需要查看CPU利用率、磁盘队列长度和IO字节，以便第一次了解正在发生的事情。|174691|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

As many have already pointed out, you probably didn't attack the real bottleneck. Randomly changing parts (or code for that matter) is as one could say "bass ackwards". 
You first identify the performance bottleneck and then you changesomething. 

Perfmon can help you get a good overview if you're CPU or I/O bound, you want to look at CPU utilization, disk queue length and IO bytes to get a first glimpse on what's going on.

blocks|key|174745|text|这实际上是一个相当大的速度，因为只是更换硬盘。此时您可能是内存或CPU绑定的。现在1.5GB很轻，RAM也很便宜。随着内存的增加，您可能会看到一些相当大的改进。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|174746|作为建议，如果安装了多个驱动器，则可以尝试将构建目录设置为与源文件不同的磁盘上的某个位置。|174747|关于这一评论：|174748|174749|+--如果您的1200个cpp文件位于一个项目中，您可能没有使用所有的CPU。如果我没有弄错的话，C6600就是四核CPU.|blockquote|174750|174751|174752|实际上，C6600不是任何东西。有一个E6600和一个Q6600。E6600是双核，Q6600是四核。在我的开发机器上，我使用了四核CPU，虽然我们的项目有超过1200个文件，但在编译期间它仍然很容易受到处理器的限制(尽管更快的硬盘仍然有助于加快速度！)|174753|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|T|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|W|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|O|$]]

That is actually a pretty big bump in speed for just replacing a hard disk. You are probably memory or CPU bound at this point. 1.5GB is light these days, and RAM is very cheap. You might see some pretty big improvements with more memory.

Just as a recommendation, if you have more than one drive installed, you could try setting your build directory to be somewhere on a different disk than your source files.

As for this comment: 

<blockquote>
 If your 1200 cpp files are in a single project, you're probably not using all of your CPU. If I'm not mistaken a C6600 is a quad-core CPU.
</blockquote>

Actually, a C6600 isn't anything. There is a E6600 and a Q6600. The E6600 is a dual core and the Q6600 is a quad core. On my dev machine I use a quad core CPU, and although our project has more than 1200 files, it is still EASILY processor limited during compile time (although a faster hard drive would still help speed things up!).

blocks|key|298034|text|1200源文件是很多的，但没有一个文件可能超过几百K，所以虽然它们都需要读入内存，但这样做不会花费很长时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|298035|把你的系统内存撞到4G上(是的，我知道32位OSes的3.一些东西或其他限制)，也许看看你的CPU比仅仅使用一个更快的磁盘驱动器可以提供更多的性能改进。|298036|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

1200 Source files is a lot, but none of them is likely to be more than a couple hundred K, so while they all need to be read into memory, it's not going to take long to do so.

Bumping your system memory to 4G (yes, yes I know about the 3.somethingorother limit that 32-bit OSes have), and maybe looking at your CPU are going to provide a lot more performance improvement than merely using a faster disk drive could.

blocks|key|174714|text|VC+2005在每个项目的时间内不会编译多个文件，所以要么转到VC+2008以使用两个CPU核心，要么将解决方案分解到多个库子项目以获得多个编译。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|174715|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

VC 2005 does not compile more then one file at the time per project so either move to VC 2008 to use both of your CPU cores, or break your solution to multiple libraries sub projects to get multiple compilations going.

blocks|key|174719|text|我把我所有的源代码都放在一个内存驱动器上，从而使我的编译时间减半。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|174720|我试过这些家伙http://www.superspeed.com/desktop/ramdisk.php，安装了一个1GB的驱动器，然后把我所有的源代码拷贝到上面。如果直接从RAM构建，IO开销就会大大减少。|offset|length|174721|让你知道我在编纂什么，以及什么；|174722|174723|WinXP+64位|unordered-list-item|174724|4GB+ram|174725|2？projects|174726|approx+250+core.+GHz双核处理器|174727|62+C#+|174728|174729|我的身材从135+s到65+s。|174730|缺点是您的源文件存在于RAM中，因此您需要更加警惕源代码管理。如果你的机器失去了动力，你就会失去所有不可逆的改变。当您关闭机器时，一些RAMdrives会将自己保存到磁盘中，这稍微减轻了一些影响，但是，从上次结帐到最后一次关闭，您仍然会失去所有的东西。|174731|另外，你还得为软件付费。但既然你想要硬盘，也许这没什么大不了的。|174732|优点是编译时间的增加，以及exes已经存在于内存中的事实，因此启动时间和调试时间要好一些。不过，真正的好处是编译时间。|174733|entityMap|0|LINK|mutability|MUTABLE|url|http://www.superspeed.com/desktop/ramdisk.php^0|0|7|19|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1B|8|@]|9|@$D|1C|E|1D|1|1E]]|A|$]]|$1|F|3|G|5|6|7|1F|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|1H|8|@]|9|@]|A|$]]|$1|L|3|M|5|K|7|1I|8|@]|9|@]|A|$]]|$1|N|3|O|5|K|7|1J|8|@]|9|@]|A|$]]|$1|P|3|Q|5|K|7|1K|8|@]|9|@]|A|$]]|$1|R|3|S|5|K|7|1L|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1N|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1O|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1P|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]]|13|$14|$5|15|16|17|A|$18|19]]]]

I halved my compilation time by putting all my source onto a ram drive. 

I tried these guys <a href="http://www.superspeed.com/desktop/ramdisk.php" rel="nofollow noreferrer">http://www.superspeed.com/desktop/ramdisk.php</a>, installed a 1GB ramdrive, then copied all my source onto it. If you build directly from RAM, the IO overhead is vastly reduced.

To give you an idea of what I'm compiling, and on what;

<ul>
<li>WinXP 64-bit </li>
<li>4GB ram</li>
<li>2.? GHz dual-core processors</li>
<li>62 C# projects</li>
<li>approx 250kloc.</li>
</ul>

My build went from about 135s to 65s. 

Downsides are that your source files are living in RAM, so you need to be more vigilant about source control. If your machine lost power, you'd lose all unversioned changes. Mitigated slightly by the fact that some RAMdrives will save themselves to disk when you shut the machine down, but still, you'll lose everything from either your last checkout, or the last time you shut down. 

Also, you have to pay for the software. But since you're shelling out for hard drives, maybe this isn't that big a deal. 

Upsides are the increased compilation time, and the fact that the exes are already living in memory, so the startup time and debugging time is a bit better. The real benefit is the compilation time, though.

Several people round here recommended switching to the new WD Velociraptor 10000rpm harddisk. Also magazine articles praise the performance. 
I bought one and mirrored my old system to it. The resulting increase in compilation-speed is somewhat disappointing:

<ul>
<li>On my old Samsung drive (SATA, 7200), the compilation time was 16:02.</li>
<li>On the Velociraptor the build takes 15:23.</li>
</ul>

I have a E6600 with 1.5G ram. It's a C++-Project with 1200 files. The build is done in Visual Studio 2005. The acoustic managment is switchted off (no big difference anyway).

Did something go wrong or is this modest acceleration really all, I can expect?

Edit: 
Some recommended increasing the RAM. I did now and got a minimal gain (3-5%) by doubling my RAM to 3GB.

Why doesn't WD Velociraptor speed up my VC++-compilation significantly?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

这里有几个人建议改用新的WD伶盗龙10000 the 硬盘。同时杂志上的文章也赞扬了这一表演。我买了一个，并将我的旧系统映射到它上。因此，编译速度的提高有点令人失望：在我的旧三星硬盘上的16:02.On  (SATA，7200)，编译时间是15:23.的伶盗龙构建我有一个E6600和1.5克的公羊。这是一个有1200个文件的C++项目。生成是在2005中完成的。声学管理被关闭了(反正没有太大的区别

问为什么WD伶盗龙不显着地加速我的VC++编译？
EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么WD伶盗龙不显着地加速我的VC++编译？EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么WD伶盗龙不显着地加速我的VC++编译？
EN