Use pre-compiled headers technology to accelerate compilation speed - taking Borland C Builder as an Example (3)
Author: moli.mt88g@nctu.edu.tw Institute of Technology Management Jiaotong University, Wang Sen Taiwan
In a paragraph in front, we get a hypothesis via inference. Next, we must prove whether our inquiry is correct. So we start modifying unit1.cpp and unit2.cpp, as follows:
Code 5: Unit1.cpp # include
Compiling the number of compiled lines First (build) 202509.18
The program code based on the test results 4 based on the test results 4 is exactly the same, in addition to the header introduced by the compiler command #pragma HDRSTOP, we have changed him to two files. Compare this test result with the test results 4, the number of compilation lines is half.
We will observe the lib directory under the directory of BCB. At this time, there will be only two files before testing, and they are: vcl50.csm, VCL50. # 00, respectively.嘿嘿 ~ Sure enough, as we expected, the compiler does not have a cache file for each file that uses the compiler command #pragma HDRSTOP, but a project, how many "pre-compiled tags", compile How many VCL50. # ?? files can be generated, which can effectively reduce space that needs to be spent in these Cache files.
Through the above experiment, we prove that our previous assumptions are correct. However, there is a saying: "The compiler will generate a cache file for each file that uses the compiler command #pragma HDRSTOP to accelerate compilation. Pre-compiling tags produce different cache files to accelerate compilation.
As for the pre-compilation mark, what is the way to record? There are only four ways to be more likely to:
Use registry
2. Data structure inside the compiler
3. Generate a pre-compilation mark database
4. Direct record in VCL50. # ??
Everyone should remember that when we are doing the above experiments, you can delete those Cache files yourself, so individuals believe that 1, 2 is more impossible, while 3, 4 is a relatively possible way. The author's self-use tool detects whether registry has changed each time compiled, and the result found that registry did not change; if it was the data structure inside the compiler, it is bound to build pre-compilation information for each Project, but later the author himself After experimenting, it was found that these pre-compiled cache files can be "cross project", which means that these Cache files can make each project share, the compiler is only concerned about whether the pre-compiled mark is only worked. exist. However, when the author uses UltraEdit to open VCL50.csm and VCL50. # ??, the author uses the UltraEdit's search function to search for the two files in these two files. After the strings like iostream or stdio, the VCL50 can be presented. .csm is more similar to 3 practice, while VCL50. # ?? Compare similar 4 practices, maybe Borland's engineers are useful! Since lack more detailed information, you can't do more detailed analysis, if Some readers have studied the results, don't forget to tell you! Finally, we use the compiler when compiling the original code, the compiler is drawn under the following flow chart:
Unit1.cppUnit1.cpp # include
◎ Test results è
Compiling the number of compiled lines Compile time first (build) 40445112.92
◎ Produced cache gear è vcl50.csm, vcl50. # 00, vCL50. # 01 Adjustment 2: Let the header files are different
Unit1.cppUnit1.cpp # include
◎ Test results è
Compiling the number of compile numbers in the first time (build) 40445111.12
◎ Produced cache gear è vcl50.csm, vcl50. # 00, vcl50. # 01 Adjustment 3: A space between the header file name
Unit1.cppUnit1.cpp # include
◎ Test results è
Compiling the number of compiled lines Compile time First (build) 2022515.40 ◎ Produced Cache file
èvcl50.csm, vcl50. # 00
From the above three adjustment program code, we can get the following conclusions:
The pre-compilation mark is determined by the header introduced by the compiler instruction #pragma HDRSTOP, and the two program raw files must be "pre-compiled markers" condition:
1. The introduced header file is exactly the same
2. The order of the header file is correct.
3. If there is any compiler command #define, its content is also the same (exported by 2)
4. The size of the header file file must also be consistent (case-sensitive)
5. As for the presence or absence of blanks, the pre-compilation mark does not constitute an impact.
All in all, in addition to blank line, each file is long before one model, and there is a difference to cause pre-compilation markers.
So we can say:
If the pre-compiled heads technology is to be used, we should let each program in the program introduce the same header file, even if the function in the header file is not in the original file of the program. It is also necessary to introduce. Hey! Next, someone will complain about me: "Then there is 100 programs in my project, and each time I have introduced a header file in the original file, then I will fix other 99 files, let the header files introduced in each file, isn't it tired? " In this problem, we have led to the best solution, and this method can also speed up our method of accelerating compilation speed when using Build (Chong to Tail recompilation), that is:
Move all the #include instructions all into a single header file, then each file inside Project is directly introduced into this single header file. " The header is called includeall.h. The content of this file is as follows:
Includeall.h
#include
#include
#include
Then modify unit1.cpp with unit2.cpp:
Unit1.cpp
#include "incrudeall.h"
#pragma HDRSTOP
#pragma argsused
Int main (int Argc, char * argv [])
{
COUT << "Hello World";
Return 0;
}
Unit2.cpp
#include "incrudeall.h"
#pragma HDRSTOP
#include "unit2.h"
Void test (void)
{
Printf ("test");
}
After that, when a program original file needs to introduce a header file, you can modify include Includeall.h, so you can make all program raw files all have the same pre-compilation, Let Pre-Compiled Headers technology to the most, and programming designers can save a lot of time to update each program's original file.
Of course, there are more lazy people will ask: "Why don't you write #pragma hdrstop directly in the includeall? This is not that we can play this line in the original file of each program?" Very good, the author is such a lazy engineer, but it actually tried it, found that there is a problem like this.
The compiler does use Pre-Compiled Headers technology, however, the compiler makes all the original code as a different pre-compilation mark, that is, if there is 40 files in Project to introduce includeall.h, Then there will be 40 cache, and the size is all the same. This will not only make compilation speeds (because almost every proprimacy of the original file is recompiled), but also because of the multi-Cache file. Wasing the overall time, also wasting the hard disk space, please don't write #pragma hdrstop inside in Includeall.h. As for why this happens? Finally let the pen in the BCB on-line help under the place where #pragma hdrstop is found below:
"Use this pragma directive only in source files. The pragma Has No Effect When IT IT IN A Header File."
Although not mentioned, there is a counter-effect, but at least this line shows that the compiler command #pragma HDRSTOP is not effective in the header file (even if we change the attachment name from .h. CPP) use).
Call ~ In order to get this result, spend our great effort!!
