Название: Как ускорить компиляцию с помощью предкомпилированных заголовков в С Builder

Вид работы: статья

Рубрика: Информатика

Размер файла: 17.32 Kb

Скачать файл: referat.me-132874.docx

Краткое описание работы: Как ускорить компиляцию с помощью предкомпилированных заголовков в С++ Builder Серебров Борис Precompiled headers can dramatically increase compilation speeds ...

Как ускорить компиляцию с помощью предкомпилированных заголовков в С Builder

Как ускорить компиляцию с помощью предкомпилированных заголовков в С++ Builder

Серебров Борис

Precompiled headers can dramatically increase compilation speeds ...

С++ Builder Language Guide

Вместо вступления сразу приведу пример. Полная сборка (build) проекта, содержащего около 170 cpp-модулей, при использовании предкомпилированных заголовков происходит за 811 секунд, при этом число обработанных компилятором строк составляет 1,808,780. При компиляции того же проекта без использования предкомпилированных заголовков, время сборки составляет 2399 секунд, а число строк, обработанных компилятором - 45,261,820. Впечатляет, не так ли? Плата за это ускорение, в принципе не велика - предкомпилированный образ, размер которого около 40 Мб.

При компиляции исходных текстов, компилятор должен обработать все *.cpp файлы проекта и все включенные в них *.h - файлы. При этом обрабатываются как пользовательские заголовочные файлы, так и стандартные, такие как vcl.h или Word2k.h. Количество кода, находящегося в стандартных заголовках может быть очень большим, например размер файла Word2k.h превышает 5 Мб, в нем больше 130 000 строк кода.

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

Принцип действия предкомпилированных заголовков

Для управления предкомпилированными предназначена директива компилятора #pragma hdrstop. Все заголовочные файлы, включенные до этой директивы, помещаются в один образ, например:

#include <vcl.h>

#include <string>

#pragma hdrstop

Такая последовательность создаст образ, содержащий скомпилированные vcl.h и string. Этот образ будет использован для другого cpp-файла, если в нем до директивы hdrstop будут включены те же файлы, в том же порядке. Обращу внимание, что важен не только состав, но и порядок следования заголовков - даже если следующий cpp-файл включает те же заголовки, но сначала указан string, а потом vcl.h, то для этого cpp-файла будет создан новый образ.

Таким образом, для повторного использования предкомпилированного заголовка необходимо выполнение двух условий:

- состав включенный файлов до директивы hdrstop должен быть тем же

- последовательность включения файлов до директивы hdrstop должна быть той же

Сократить затраты на компиляцию стандартных заголовков до минимума можно только в том случае, если скомпилировать один образ, содержащий все стандартные заголовки, необходимые для проекта. Для этого нужно, чтобы:

- ВСЕ cpp-файлы проекта имели одинаковый блок включений до директивы hdrstop

- в этот блок должны входить ВСЕ стандартные заголовочные файлы, необходимые для проекта

Выполнить эти условия достаточно просто, для этого в начало каждого cpp-файла необходимо поместить следующие строки:

#include <pch.h>

#pragma hdrstop

где pch.h - файл, содержащий включения всех стандартных заголовков:

#ifndef PCH_H

#define PCH_H

#define INC_VCLDB_HEADERS

#define INC_VCLEXT_HEADERS

#include <vcl.h>

#include <sysset.h>

#include <IniFiles.hpp>

#include <AppEvnts.hpp>

#include <ActnMan.hpp>

...

#endif

Полный текст моей версии этого файла приведен в конце статьи. На h-файлы, входящие в предкомпилированный образ, накладывается ограничение - в них не должно быть инициализированных данных, например, в math.hpp есть строки:

static const Extended NaN = 0.0 / 0.0;

static const Extended Infinity = 1.0 / 0.0;

Из-за наличия этих констант включить math.hpp в файл pch.h нельзя.

Кстати, С++ Builder при добавлении новых модулей в проект реализует описанную стратегию управления предкомпилированными заголовками. Например, при создании нового приложения, файл Unit1.cpp будет таким:

#include <vcl.h>

#pragma hdrstop

#include "Unit1.h"

....

Если посмотреть на текст vcl.h, то можно увидеть, что он является оболочкой для включения большого числа других стандартных заголовочных файлов.

Управлять составом включаемых в vcl.h заголовков можно с помощью специальных символов (INC_VCLDB_HEADERS, INC_VCLEXT_HEADERS и др.). В моей версии pch.h эти символы определяются с помощью #define до включения vcl.h, что приводит к увеличению числа включаемых файлов.

Как в существующем проекте перейти к использованию предкомпилированных заголовков

Даже в большом проекте перейти к использованию предкомпилированных заголовков достаточно просто.

В свойствах проекта нужно включить кэширование предкомпилированных заголовков и рекомендуется указать "персональный" файл, в котором будет храниться образ предкомпилированных заголовков: Project - Options - закладка Compiler, группа "Pre-compiled headers". Тут должно быть выбрано "Cache pre-compiled headers", а в поле "File Name" нужно ввести "pch.csm". При такой настройке образ с предкомпилированными заголовками будет находится в папке с проектом, в файле pch.csm.

После этого в начало каждого cpp-модуля необходимо вставить 2 строки:

#include "pch.h"

#pragma hdrstop

Все ранее включенные заголовочные файлы остаются на своих местах, их удалять не надо. Например:

#include "pch.h" // включает vcl.h, string и т.д.

#pragma hdrstop

#include <vcl.h>

#include <string>

...

Так как во всех стандартных заголовках применяются стражи повторного включения, то повторное их упоминание не влечет за собой повторного включения.

В принципе, при использовании pch.h, техническая потребность во включении стандартных заголовков исчезает. Однако, полезно все же указывать все необходимые для каждого конкретного модуля заголовки ниже директивы #pragma hdrstop. Во-первых, это в некоторой степени документирует модуль - по включаемым файлам можно судить, какими возможностями пользуется этот модуль. Во-вторых, это облегчает повторное использование модуля в других проектах, в которых либо не используется pch.h, либо его содержимое может быть другим.

Теоретически можно еще больше повысить эффективность компиляции, если включить в pch.h не только стандартные, но и все пользовательские заголовочные файлы. Практически, так как пользовательские заголовки меняются достаточно часто, это может повлечь за собой частую перекомпиляцию pch.h, что негативно скажется на времени компиляции. Кроме того, пользовательские заголовки обычно не бывают очень большими и компилируются очень быстро. Поэтому включать их pch.h не целесообразно.

Как проверить, что предкомпилированные заголовки используются эффективно

При добавлении в проект новых файлов нужно не забывать включать в них pch.h, иначе для них не будет использован общий предкомпилированный образ. Такая же ситуация может возникнуть, если в каком-то модуле включаются стандартные заголовки, которые не вошли в pch.h. Для того, чтобы отследить такие файлы, есть несколько способов:

- визуальное наблюдение за процессом компиляции. Обычно, число строк компилируемых в одном файле не должно превышать 10000-15000 строк

- если для проекта выбран индивидуальный файл для хранения образа предкомпилированных заголовков и этот файл называется pch.csm, то нужно обратить внимание на наличие вспомогательных файлов с именами pch.#00, pch.#01 и т.д. Если для всех файлов проекта используется один и тот же предкомпилированный образ, то вспомогательный файл должен быть только один - pch.#00. Если таких файлов больше, это значит что для каких-то cpp-модулей создаются дополнительные образы.

Текст pch.h

#ifndef PCH_H

#define PCH_H

#define INC_VCLDB_HEADERS

#define INC_VCLEXT_HEADERS

#include <vcl.h>

/* Все, что подключается предыдущими 3-мя строчками

// Core (minimal) Delphi RTL headers

#include <System.hpp>

#include <Types.hpp>

#include <Windows.hpp>

#include <Messages.hpp>

#include <SysUtils.hpp>

#include <Classes.hpp>

// Core (minimal) VCL headers

#if defined(INC_VCL)

#include <Controls.hpp>

#include <Graphics.hpp>

#include <Forms.hpp>

#include <Dialogs.hpp>

#include <StdCtrls.hpp>

#include <ExtCtrls.hpp>

// VCL Database related headers

#if defined(INC_VCLDB_HEADERS)

#include <DBCtrls.hpp>

#include <DB.hpp>

#include <DBTables.hpp>

#endif // INC_VCLDB_HEADERS

// Full set of VCL headers

#if defined(INC_VCLEXT_HEADERS)

#include <Buttons.hpp>

#include <ChartFX.hpp>

#include <ComCtrls.hpp>

#include <DBCGrids.hpp>

#include <DBGrids.hpp>

#include <DBLookup.hpp>

#include <DdeMan.hpp>

#include <FileCtrl.hpp>

#include <GraphSvr.hpp>

#include <Grids.hpp>

#include <MPlayer.hpp>

#include <Mask.hpp>

#include <Menus.hpp>

#include <OleCtnrs.hpp>

#include <OleCtrls.hpp>

#include <Outline.hpp>

#include <Tabnotbk.hpp>

#include <Tabs.hpp>

#include <VCFImprs.hpp>

#include <VCFrmla1.hpp>

#include <VCSpell3.hpp>

#endif // INC_VCLEXT_HEADERS

#endif // INC_VCL

*/

#include <sysset.h>

#include <IniFiles.hpp>

#include <AppEvnts.hpp>

#include <ActnMan.hpp>

#include <ActnCtrls.hpp>

#include <BandActn.hpp>

#include <CustomizeDlg.hpp>

#include <ImgList.hpp>

#include <ToolWin.hpp>

#include <ExtDlgs.hpp>

#include <ActnList.hpp>

#include <IBDatabase.hpp>

#include <IBCustomDataSet.hpp>

#include <IBQuery.hpp>

#include <IBTable.hpp>

#include <IBSQL.hpp>

#include <IBServices.hpp>

#include <math.h>

#include <assert.h>

#include <complex.h>

#include <values.h>

#include <map>

#include <list>

#include <set>

#include <vector>

#include <algorithm>

#include <functional>

#include <string>

#include <memory>

#include <fstream>

//нестандартные компоненты RxLib и EhLib

#include "CURREDIT.hpp"

#include "RXSpin.hpp"

#include "RxCalc.hpp"

#include "RxCombos.hpp"

#include "APPUTILS.hpp"

#include "RXDBCtrl.hpp"

#include "Placemnt.hpp"

#include "DBGridEh.hpp"

#endif