Почему не делает WD, Velociraptor ускоряют мой VC ++-compilation значительно?

Я предполагаю, что чтение жесткого диска не было Вашим узким местом в компиляции. Реалистично, немного вещей должны читаться/писаться из жесткого диска. Вы, вероятно, видели бы, что больше производительности увеличивается с большего количества поршня или быстрого процессора.

Visual Studio 2005 может разработать несколько проектов параллельно и сделает так по умолчанию на многоядерной машине, но в зависимости от того, как Ваши проекты зависят друг от друга, это может не мочь быть параллельным, создают их.

Если Ваши 1 200 cpp файлов находятся в единственном проекте, Вы, вероятно, не используете весь свой ЦП. Если я не ошибаюсь, C6600 является четырехъядерный ЦП.

Dave

Я предположил бы от результатов, что или Ваша скорость задержки HDD не была узким местом, которое Вы искали, или что Ваш проект уже близко к созданию максимально быстро. Другие объекты для рассмотрения были бы:

1. время доступа HDD (хотя Вы не можете делать много с этим из-за ограничений скорости шины),
2. Скорость доступа RAM и размер
3. Скорость процессора
4. Сокращение фоновых процессов

Увеличение на ~6% скорости только от улучшения Вашего жесткого диска. Точно так же, как сказанный Зуммер. Захватите некоторый более быстрый поршень и PCU.

Как многие уже указали, Вы, вероятно, не напали на реальное узкое место. Случайным образом изменяющиеся части (или код в этом отношении) - поскольку можно было сказать "бас ackwards". Вы сначала определяете узкое место производительности и затем Вас changesomething.

Perfmon может помочь Вам получить хороший обзор, если Вы - ЦП или связанный ввод-вывод, Вы хотите посмотреть на загрузку ЦП, дисковую длину очереди и байты IO для получения первого представления на том, что продолжается.

1 200 Исходных файлов много, но ни один из них, вероятно, не будет больше чем парой сотни K, поэтому в то время как они все должны быть считаны в память, она не собирается занимать много времени делать так.

Ударение Вашей системной памяти к 4G (да, да я знаю о 3.somethingorother предел, который 32-разрядные Ose имеют), и возможно рассмотрения Вашего ЦП собирается обеспечить намного больше повышения производительности, чем просто использование более быстрого дисковода могло.

Это - на самом деле довольно большой удар в скорости для того, чтобы просто заменить жесткий диск. Вы - вероятно, память или зависящий от ЦП в этой точке. 1.5 ГБ легки в эти дни, и RAM является очень дешевой. Вы могли бы видеть некоторые довольно большие улучшения с большей памятью.

Так же, как рекомендация, если у Вас есть больше чем один установленный диск, Вы могли бы попытаться установить свой каталог сборки, чтобы быть где-нибудь на другом диске, чем Ваши исходные файлы.

Что касается этого комментария:

Если Ваши 1 200 cpp файлов находятся в единственном проекте, Вы, вероятно, не используете весь свой ЦП. Если я не ошибаюсь, C6600 является четырехъядерный ЦП.

На самом деле C6600 - ничто. Существует E6600 и Q6600. E6600 является двухъядерным, и Q6600 является четырехъядерным. На моей dev машине я использую четырехъядерный ЦП, и хотя наш проект имеет больше чем 1 200 файлов, это - все еще процессор EASILY, ограниченный в течение времени компиляции (хотя более быстрый жесткий диск все еще помог бы вещам скорости встать!).

Я разделил на два свое время компиляции путем помещения всего моего источника на электронный диск.

Я судил этих парней http://www.superspeed.com/desktop/ramdisk.php, установил 1 ГБ ramdrive, затем скопировал весь мой источник на него. Если Вы создаете непосредственно из RAM, IO наверху значительно уменьшается.

Дать Вам общее представление о том, что я компилирую, и на какой;

• 64-разрядный WinXP
• Поршень на 4 ГБ
• 2.? GHz двухъядерные процессоры
• 62 проекта C#
• приблизительно 250kloc.

Моя сборка перешла приблизительно с 135 с к 65.

Оборотные стороны - то, что Ваши исходные файлы живут в RAM, таким образом, необходимо быть более бдительны в отношении управления исходным кодом. Если бы Ваша машина потеряла питание, то Вы потеряли бы все неимеющие версию изменения. Смягченный немного тем, что некоторый RAMdrives сохранит себя на диск, когда Вы завершите работу машины, но тем не менее, Вы потеряете все или от Вашего последнего контроля или в прошлый раз от, Вы закрываетесь.

Кроме того, необходимо заплатить за программное обеспечение. Но так как Вы выходите из оболочки для жестких дисков, возможно, это не то, что большое соглашение.

Позитивные аспекты являются увеличенным временем компиляции, и то, что exes уже живут в памяти, таким образом, время запуска и отлаживают время, немного лучше. Реальная выгода является временем компиляции, все же.

VC 2005 не компилирует более затем один файл в то время на проект так или перемещает в VC 2008, чтобы использовать оба из Ваших ядер процессора или повредить Ваше решение нескольких подпроектов библиотек для получения нескольких движения компиляций.