DiscussionsIssue archiveOCCT:Configuration

Archived issue #0027407

Accelerate OCCT build on Visual Studio by use of precompiled headers

Open CASCADEOCCT:Configurationclosed31 public notes

Search issues

Description

As proven by OCE experience, use of precompiled headers feature of Visual Studio can considerably accelerate process of building OCCT from sources (by ~ 3.5 times, see http://dev.opencascade.org/index.php?q=node/1158 for discussion).

Though not suitable for OCCT development, acceleration via use of PCH would be quite useful for certification testing: it can reduce build time by ~ 20 min.

Steps to reproduce

Configure, generate and build occt with BUILD_USE_PRECOMPILED_HEADER_FILES=ON
Result: reduced build time

Public activity

31 archived notes

Participants are labeled by their role within this record.

01Commenter 2
Branch [archived branch] has been created by Participant.

[revision removed]


Detailed log of new commits:

Author: ski
Date: Mon May 30 14:54:47 2016 +0300

    Corrected comment in OSD_signal.cxx file

Author: ski
Date: Mon May 30 15:06:48 2016 +0300

    0027407: Accelerate OCCT build on Visual Studio by use of precompiled headers
    
    Added cmake functionality to generate and use precompiled header files.
02Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
03Commenter 2
Branch [archived branch] has been updated by Participant.

[revision removed]


Detailed log of new commits:

Author: ski
Date: Wed Jun 1 17:20:38 2016 +0300

    Eliminate compile warnings and errors.

Author: ski
Date: Tue May 31 14:55:05 2016 +0300

    Exclude problem header files names from pch file.

Author: ski
Date: Mon May 30 16:27:38 2016 +0300

    Apply using of precompiled header files only on *.cxx files.

04Commenter 3
PLib_JacobiPolynomial_0.hxx
+#ifndef PLib_JacobiPolynomial_0_HeaderFile
+#define PLib_JacobiPolynomial_0_HeaderFile

it seems this header is designed for internal use.
It is better renaming it to "PLib_JacobiPolynomial.pxx" and including without angles in .cxx.

05Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
06Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
07Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
08Commenter 8
Dear abv,

branch CR27407 was rebased on current state of master and squashed.
New CMake option BUILD_USE_PRECOMPILED_HEADER_FILES was added.

Please, review.
09Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
10Commenter 2
Branch [archived branch] has been updated by Participant.

[revision removed]


Detailed log of new commits:

Author: ski
Date: Thu Jun 2 15:50:44 2016 +0300

    Search for tclsh executable was added.

11Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
12Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
13Commenter 2
Branch [archived branch] has been updated by Participant.

[revision removed]


Detailed log of new commits:

Author: ski
Date: Thu Jun 2 17:24:20 2016 +0300

    Updated documentation.

Author: ski
Date: Thu Jun 2 17:15:19 2016 +0300

    Standard output during generation of precompiled header files was silenced.

14Commenter 14
Remarks:

1. It is very bad practice to treat some source files differently from others basing on hard-coded lists, as done in occt_toolkit.cmake -- this is very obscure and it will be extremely hard to debug (except for the author who knows the trick). Please find a way to either avoid this need at all, or at least implement it in a way so that files that need to be excluded from PCH could be marked individually.

2. Why using TCL for generating header files? I suppose this can be done by standard CMake tools as well. It is highly desirable to avoid dependency on TCL for generation of projects by CMake (consider that DRAW is optional, hence the TCL may not be present).

3. Changes in sources where some macro names are changed to avoid conflicts should be revised to avoid meaningless name variations like TRACE -> aTRACE. The best variant is to avoid such macros in header files at all. When not possible, names should be changed to class or package specific, e.g. Interface_TRACE

4. In PLib_JacobiPolynomial.cxx, inclusion of pxx file should be separated from normal headers, to highlight that it is part of the code and not header

5. In TopOpeBRepBuild_ShapeListOfShape.cxx, the #define in the beginning of the file seem to be completely unnecessary and can be removed
15Commenter 15
Besides, have a look at #pragma hdrstop declaration -- probably it can be used to disable precompiled header for a particular file

16Commenter 2
Branch [archived branch] has been created by Participant.

[revision removed]


Detailed log of new commits:

Author: ski
Date: Mon Jun 6 15:05:23 2016 +0300

    0027407: Accelerate OCCT build on Visual Studio by use of precompiled headers
    
    Added cmake functionality to generate and use precompiled header files.
    Corrected comment in OSD_signal.cxx file.
    Applied using of precompiled header files only on *.cxx files.
    Excluded problem header files names from pch file.
    Eliminated compile warnings and errors.
    Search for tclsh executable was added.
    Standard output during generation of precompiled header files was silenced.
    Updated documentation.
17Commenter 2
Branch [archived branch] has been updated by Participant.

[revision removed]


Detailed log of new commits:

Author: ski
Date: Tue Jun 7 15:39:27 2016 +0300

    Eliminated compile warning for debug configuration.

18Commenter 3
-      memcpy (ChangeData(), theCopy.Data(), std::min (SizeBytes(), theCopy.SizeBytes()));
+      memcpy (ChangeData(), theCopy.Data(), (std::min) (SizeBytes(), theCopy.SizeBytes()));

what does (std::min) is supposed to do?
How this helps with conflicting max/min macros (which I suppose the reason for this code)?

 #ifdef _WIN32
+#ifdef _WIN32_WINNT
+#undef _WIN32_WINNT
+#endif
 #define _WIN32_WINNT 0x0400  // for trackmouseevent support  requires Win95 with IE 3.0 or greater.
 #include <windows.h>

I suppose OCCT7+ can not be built by compiler for so old versions of Windows.
Please try removing these defines at all and check compilation on the oldest supported compiler (msvc2010).
19Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
20Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
21Commenter 2
Branch [archived branch] has been created by Participant.

[revision removed]


Detailed log of new commits:

Author: ski
Date: Fri Jun 10 12:46:13 2016 +0300

    0027407: Accelerate OCCT build on Visual Studio by use of precompiled headers
    
    Added cmake functionality to generate and use precompiled header files.
22Commenter 2
Branch [archived branch] has been updated forcibly by Participant.

[revision removed]
23Commenter 23
Dear abv,

as it has been discussed, occt branch CR27407_2 contains procedure to create precompiled header files via CMake only.
Header files <TOOLKIT_NAME>.hxx (contains all header files of current toolkit, it will be installed during installation procedure) and
<TOOLKIT_NAME>.h (precompiled header file, contains includes of necessary <TOOLKIT_NAMES>.hxx) are created during configuration via CMake.
Both header files are located in "${CMAKE_BINARY_DIR}/inc" during building.

It seems that current approach could not reduce compilation time according to huge number of header files in pch.


Branch CR27407_1 contains procedure to create precompiled header files via tcl script.
It takes only included in source files headers to the precompiled header file <TOOLKIT_NAME>.h.
Compilation time of such approach is much faster than in branch CR27407_2


Another way of using of pch is not to generate pch files but take already generated files from branch CR27407_1, and generate only <TOOLKIT_NAME>.hxx API header files which will be installed and will not be used during building (such as in CR27407_2).
24Commenter 2
Branch [archived branch] has been updated forcibly by Author.

[revision removed]
25Commenter 2
Branch [archived branch] has been updated forcibly by Author.

[revision removed]
26Commenter 26
I have rebased both branches on current master and tested with VC 10 and VC 14. Unfortunately, both fail to build (in the same way for VC 10 and VC14):

CR27407_1: compiler error in TKDraw.cpp due to macro "Opposite" defined in X11.h (included via tcl.h) that conflicts with math_Vector::Opposite

CR27401_2: linker error in TKDCAF and other libs that use TKStd, due to missing symbol ShapePersistent_Poly::pTriangulation::Import (required for some unclear reason, due to reference from some template instance). In addition, VC 14 fails sporadically when many files are built due to PCH heap overrun (suggests uzing -Zm104); the same files are built fine on the next build.

I have also played a bit with PCH and found them to be totally unusable: any change causes new kinds of errors that are extremely difficult to trace and understand. For instance, modifying CR27401_2 so as to keep only own toolkit .hxx in PCH header, I got errors in winnt.h when including OSD_Thread.hxx in TKGeomBase....

One obvuious conclusion is that PCH files cannot be generated automatically, alas. I suppose they can be generated once and put in sources, in each toolkit.

However, before proceeding with PCH, I propose trying another approach to accelerate build: instead of adding each CXX in project, add single CXX per package that #includes all CXX files of that package. The effect should be quite similar to using PCH, but more universal (not depending on compiler).
27Commenter 1
I processed only TKernel toolkit. See branch CR27401_3.
Such approach did you assume?

TKernel is not compiled such way.

The reason described in this article.
https://engineering-game-dev.com/2009/12/15/the-evils-of-unity-builds/
28Commenter 28
The support of use of precompiled headers has been introduced by fix for #0028417
29Commenter 2
Branch [archived branch] has been deleted by Commenter 3.

[revision removed]
30Commenter 2
Branch [archived branch] has been deleted by Commenter 3.

[revision removed]
31Commenter 2
Branch [archived branch] has been deleted by Commenter 3.

[revision removed]

Related records