如何针对多项目解决方案加速 Visual Studio 2008?
我知道有几个问题看起来与我的类似,例如 此处,此处,此处或此处。然而这些都没有真正回答我的问题。就这样吧。
我正在 VS2008 中构建 Chromium 浏览器的修改版本(主要是用 C++ 编写的)。它在一个解决方案中包含 500 个项目,这些项目之间存在大量依赖关系。通常有两个问题:
- 每当我在会话中第一次开始调试(按 F5 或绿色“播放”按钮)时,VS 就会冻结,需要几分钟才能恢复并实际开始调试。请注意,我在运行之前禁用了构建,因为每当我想要构建项目时,我都会明确使用 F7。我不明白为什么“仅仅”启动编译的二进制文件需要这么长时间。尽管我要求在运行之前不要构建解决方案,但 VS 可能正在检查所有部门并确保所有内容都是最新的。有一种方法可以加快这个速度吗?
- 每次执行构建时,即使我只更改了一个文件中的一条指令,也需要大约 5-7 分钟。大部分时间都消耗在链接过程中,因为大多数项目都会生成静态库,然后将其链接到一个巨大的 dll 中。显然,增量链接仅在大约 10% 的情况下有效,并且仍然需要相当长的时间。我可以做什么来加快速度?
以下是有关我的软件和硬件的一些信息:
- MacBook Pro(2010 年中)
- 8 GB RAM
- 带 HT 的双核 Intel i7 CPU(这使其在任务管理器中看起来像 4 核)
- 500GB 串行 ATA; 5400 rpm (Hitachi HTS725050A9A362)
- Windows 7 Professional 64 位
- Visual Assist X(禁用代码着色)
以下是我注意到的一些事情:
- 链接仅使用一个核心
- 在一个会话中第二次运行解决方案时,速度要快得多( 2-3 秒以内)
I am aware that there are a couple of questions that look similar to mine, e.g. here, here, here or here. Yet none of these really answer my question. Here it goes.
I am building a modified version of a Chromium browser in VS2008 (mostly written in C++). It has 500 projects in one solution with plenty of dependencies between them. There are generally two problems:
- Whenever I start debugging (press F5 or green Play button) for the first time in a session the VS freezes and it takes a couple of minutes before it recovers and actually starts debugging. Note that I have disabled building before running, because whenever I want to build my project I use F7 explicitly. I do not understand why it takes so long to "just" start a compiled binary. Probably VS is checking all the deps and making sure everything up-to-date despite my request not to build a solution before running. Is the a way speed this one up?
- Every time I perform a build it takes about 5-7 minutes even if I have only changed one instruction in one file. Most of the time is consumed by the linking process, since most projects generate static libs that are then linked into one huge dll. Apparently incremental linking only works in about 10% of the cases and still takes considerably long. What can I do to speed it up?
Here is some info about my software and hardware:
- MacBook Pro (Mid-2010)
- 8 GB RAM
- dual-core Intel i7 CPU with HT (which makes it look like 4-core in Task Manager)
- 500GB Serial ATA; 5400 rpm (Hitachi HTS725050A9A362)
- Windows 7 Professional 64-bit
- Visual Assist X (with disabled code coloring)
Here are some things that I have noticed:
- Linking only uses one core
- When running solution for the second time in one session it is much quicker (under 2-3 seconds)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在查找有关 VS 链接器的信息时,我遇到了此页面:
http://msdn.microsoft.com/en-us/library/whs4y2dc%28v=vs.80%29.aspx
另请查看另外两个主题在该页面上:
while looking up information on VS linker I came across this page:
http://msdn.microsoft.com/en-us/library/whs4y2dc%28v=vs.80%29.aspx
Also take a look the two additional topics on that page:
我已经切换到 Chromium 项目的组件构建模式,这减少了需要链接的文件数量。组件构建模式创建一组较小的 DLL,而不是一组链接到巨大
chrome.dll
的静态库。另外,我经常使用增量链接,这使得链接速度更快。最后,第二次和后续次数的链接变得更快,因为必要的文件已经缓存在内存中并且不需要磁盘访问。因此,当增量工作和经常链接时,我的webkit.dll
链接时间只需 15 秒,这是我主要更改代码的地方。至于执行,它具有与链接相同的行为 - 仅第一次运行缓慢,随后的每次运行都会变得越来越快,直到启动浏览器并加载所有符号所需的时间不到 3-5 秒。 Windows 将最常访问的文件缓存到内存中。
I have switched to the component build mode for Chromium project, which reduced the number of files that need to be linked. Component build mode creates a set of smaller DLLs rather than a set of static libraries that are then linked into huge
chrome.dll
. Also I am using incremental linking a lot, which makes linking even faster. Finally linking for the second and subsequent times gets faster since necessary files are already cached in the memory and disk access is unnecessary. Thus when working incrementally and linking often, I get to as low as 15 seconds for linking ofwebkit.dll
which is where I mostly change the code.As for the execution it has same behavior as linking - it runs slow only for the first time and with every subsequent run it gets faster and faster until it takes less than 3-5 seconds to start the browser and load all symbols. Windows is caching files that are accessed most often into the memory.