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

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

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

innuendo
ну если так, то может быть, хотя у себя не замечал такой проблемы, а тоже ведь наплодили:-[

#31
8:34, 15 сен 2010

Статья улыбнула.

1. Я принципиальной разницы по компиляции между MinGW и VC не заметил. Clang быстрее, да. Borland был вообще сказкой. Линковка у GCC --- медленнее.

Если классический Make писать, когда на каждый объектник собирается отдельно --- VC будет медленнее MinGW. Если использовать конструкции вида "$CC -c $C_FILES" --- VC будет быстрее.

2. Существенный прирост скорости от PCH --- мне кажется сомнительным. Более правильный подход --- минимизация подключаемых файлов в каждом модуле.

Нужно отдельно отметить, что ни один крупный OSS проект, не использует PCH при сборке.

3. distcc и ccache могут дать выигрыш при полной пересборке проекта. Тут согласен.

4. Ram Disk ускоряет сборку на 25%. Проверено на Gentoo с 24G памяти и 8G tmpfs. Т.е. у нас достаточно эффективно работает дисковой кэш, чтобы нивелировать преимущества RamDisk. Я сильно сомневаюсь, что в Windows система кэширования менее эффективна линуксовой.

На Hot-run, выигрыш вообще мизерный.

100MB --- это небольшие проекты. С полностью включенной отладкой (-g3) из исходника С++ в 200 строк, использующего QT --- получается ~800K объектный файл.

5. qmake это система генерации файлов сборки. Ёё не нужно запускать при каждой сборке. :)

6.
> Готовые модули добавляйте в список precompiled headers.

Я правильно понимаю, что в результате у нас будет пересборка всех частей, которые используют PCH?

#32
8:38, 15 сен 2010

raid 0 помогает

#33
8:42, 15 сен 2010

nbkolchin
может быть она и не опубликована поэтому? :)
в любом случае я рад что написал ее - узнал много нового.

#34
9:53, 15 сен 2010

nbkolchin
> Существенный прирост скорости от PCH --- мне кажется сомнительным. Более
> правильный подход --- минимизация подключаемых файлов в каждом модуле.
зря. прирост в разы, особенно при использовании шаблонов, но и без них - до 5 раз из собственных тестов. и это относительно сборки, где пытались минимизировать включения хедеров - форвард декларации использовались и прочее. Особенно эффективно при подключении больших сторонних библиотек. То есть лучше включить хедер в pch, чем включить его в половину или даже треть исходников. Это проверено как на студии, так и на gcc.

>Нужно отдельно отметить, что ни один крупный OSS проект, не использует PCH при сборке.
OSS = open source software? тогда wxWidgets использует

#35
10:11, 15 сен 2010

читал, scons умеет разносить компиляцию по нескольким машинам как incredibuild - кто-нибудь пользовался? что скажете?

#36
10:25, 15 сен 2010

jaxon

> зря. прирост в разы

Давай тестовый пример.

> OSS = open source software? тогда wxWidgets использует

Она, как и QT, умеет генерировать PCH файл для библиотеки. Приложения, которые используют PCH при сборке --- мне неизвестны.

#37
10:35, 15 сен 2010

nbkolchin
> Давай тестовый пример.
ну попробуй тот же wxWidgets собрать с pch и без. под MSVC по умолчанию используетя, но можно задать при сборке через nmake константу NOPCH

> Она, как и QT, умеет генерировать PCH файл для библиотеки.
а при сборке самой себя не использует, хочешь сказать? зачем тогда в исходниках:

#include "wx/wxprec.h"

#ifndef WX_PRECOMP
    #ifdef __WXMSW__
        #include "wx/msw/private.h"
        #include "wx/msw/wrapwin.h"
        #include "wx/msw/wrapcctl.h" // include <commctrl.h> "properly"
    #endif
    #include "wx/sizer.h"
    #include "wx/log.h"
    #include "wx/dcclient.h"
    #include "wx/timer.h"
    #include "wx/settings.h"
    #include "wx/msgdlg.h"
    #include "wx/dcscreen.h"
    #include "wx/frame.h"
#endif
#38
10:35, 15 сен 2010

не упомянули что windows.h надо аккуратно инклудить в проект.

#39
11:24, 15 сен 2010

В статье сравнивается "компилятор-MSVС" с "QT"?

Как можно сравнивать скорость компилятора со скоростью фреймворка?

Если собирать приложение используещее QT под MSVС на чей счет буду зачислены тормоза такой компиляции?

#40
11:36, 15 сен 2010

jaxon

Я понял о чём речь с PCH в WxWidgets.

$ time USE="-pch" emerge wxGTK
...
real    4m43.387s
user    29m44.463s
sys     1m24.811s

$ time USE="pch" emerge wxGTK
...
real    2m52.244s
user    16m29.497s
sys     1m2.622s

Прирост есть, но не в разы. На VC должен быть больше прирост.

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

Ссылки по теме:

- http://midi-clorianos.blogspot.com/2009/12/precompiled-headers.html
- Build tools benchmark.

#41
11:39, 15 сен 2010

aloha_hawaii
не совсем понял о чем речь... в чем должна быть выражена аккуратность?

Megabyte-Ceercop
Где ты там такое сравнение увидел?

nbkolchin
Там прямым текстом написано что в PCH нужно выносить модули которые не изменяются или изменяются очень редко.

#42
11:46, 15 сен 2010

@!!ex
> Там прямым текстом написано что в PCH нужно выносить модули которые не
> изменяются или изменяются очень редко.

"Готовые модули добавляйте в список precompiled headers." --- я к этой фразе цепляюсь. :)

#43
11:49, 15 сен 2010

nbkolchin
Ну так готовые - значит готовые, и изменятся не будут. :?)

#44
11:52, 15 сен 2010

nbkolchin
> Прирост есть, но не в разы.
ну почти в 2 раза, а уменя реально было в 5 на Студии - может специфика, может можно было чего-то исключением хедеров добиться

>код самого проекта помещать в PCH смысла нет
а вот тут согласен, исключение - когда можно выделить набор редко изменяемых и часто используемых хедеров (по сути - измененние которых ведёт к пересборке существенной части проекта) и прописать в pch только их.

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

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