ПрограммированиеФорумОбщее

C++. Секреты быстрой компиляции (комментарии) (2 стр)

Страницы: 1 2 3 4 5 Следующая »
#15
23:59, 14 сен 2010

PANDA
Sh.Tac.
это многопроцессорная сборка на одном компе... охота задействовать толпу компов... это не для компиляции это для сборки ресурсов, которая на 1 компе знимает 2 часа...

#16
0:03, 15 сен 2010

Pushkoff
> это не для компиляции это для сборки ресурсов, которая на 1 компе знимает 2
> часа...

Слишком большой объем данных придется гонять по сети, - врядли это сильно, если вообще, ускорит это дело.

#17
0:03, 15 сен 2010

"Модульность" как раз очень очень сомнительная рекомендация.
Каждый раз компилер будет грузить все инклюды, грузить 100 мегабайтный PCH файл и лопатить заново каждый модуль.

Удивительные результаты достигаются если поинклюдить все *.CPP файлы из одного главного файла, и компилить его одним вызовом cl.exe.
Пример - проект SPARK (http://spark.developpez.com), компилится секунд за 3-5 без линковки, там навскидку десятка 3 файлов с шаблонами и проч.

#18
0:38, 15 сен 2010

вопрос по поводу Ram Disk а почему нельзя на Ram Disk тупо бинарники и всякие временный файлы складывать? зачем туда весь проект сувать?
и еще потом какую то синхронизацию делать? или я что то не так понял?

#19
0:42, 15 сен 2010

kvakvs
ну тут вообще сложно. в общем случае разбиение на маленькие модули работает быстрее чем, чем гигантские модули.
плюс профит в быстрой работе IDE(парсинг кода для Code Insight и аналогов) и при использовании Qt очень заметен прирост, т.к. разбор мелкий хедеров вообще мгновенно делается.

cNoNim
Можно только выходные файлы туда писать. тогда действительно нет проблем с синхронизацией и потерей инфы.
Но если и сорсы закинуть, прирост будет больше. Что важнее решать вам.

#20
0:45, 15 сен 2010

@!!ex
а в чем прирост, за счет того, что файлы будут быстрее читаться чтоли?
я что то сомневаюсь в прямо таки большом приросте

#21
0:46, 15 сен 2010

cNoNim
проценты.
хотя согласен, я не учел, что эти проценты вполне могут сожратся временем потраченным  на синхронизацию.

#22
0:49, 15 сен 2010

не упомянуто, что для увеличения скорости линковки полезно разбивать на dll
Применение рам-диска для больших проектов затруднено, мягко говоря, - у меня счас папка с pch/obj весит 768Мб, а проект не столь уж и велик в принципе

#23
0:50, 15 сен 2010

oistalker
> Слишком большой объем данных придется гонять по сети
объем не большой... много картинок которые нужно пожать, и коллада файлов которые нужно перепаковать... всего около 400 мб

#24
0:51, 15 сен 2010

jaxon
зачем на длл? на либы со статичной линковкой. (второе сообщение в теме)
не упомянуто, т.к. достаточно сложно в реализации.
хотя тема достаточно интересная, возможно стоит добавить.

#25
0:55, 15 сен 2010

jaxon
> у меня счас папка с pch/obj весит 768Мб,
может, мусор какой накопился?
или небольшой проект это скока файлов/строк?

#26
0:55, 15 сен 2010

@!!ex
> зачем на длл? на либы со статичной линковкой. (второе сообщение в теме)
статик либы по скорости линковки не сильно отличаются от obj файлов по ощущению - то же самое, что и при частичной пересборке проекта то есть.

#27
0:57, 15 сен 2010

jaxon
ну а длл скажется на скорости загрузке... одно другого не лучше. ИМХО

#28
0:58, 15 сен 2010

jaxon
> у меня счас папка с pch/obj весит 768Мб, а проект не столь уж и велик в
> принципе
фига себе. :))
Ну вообще это тоже не проблема, сейчас на компах по 8 ггб оперативы.
Выделить гектар под Ram Disk - не проблема.

#29
1:02, 15 сен 2010

jaxon
> статик либы по скорости линковки не сильно отличаются от obj файлов по ощущению
оно число берёт, тут одни паршивцы наплодили 100-500 файликов сpp с среднем размером 5-10 кб а до 1-3 либ руки не дошли, понимаешь - когда линкуется чай можно попить сходить

Страницы: 1 2 3 4 5 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.