Using Pre-Compiled Headers technology to accelerate compilation speed - Take Borland C ++ Builder as an Example (2)

zhaozj2021-02-17  35

Using Pre-Compiled Headers technology to accelerate compilation speed - Take Borland C Builder as an Example (2)

Author: Wang Sen Technology Management Institute moli.mt88g@nctu.edu.tw Taiwan Jiaotong University

In the past, we wrote a C / C program, each file must use the compiler command #include to introduce a lot of system header files to make the program smoothly, then generate the execution unit via the connection. If our Project has two archives A.CPP and B.cpp, when we use the Getch () in A.CPP, we must write at the beginning of the beginning of A.CPP. : #include Otherwise, the compiler must tell us that this version is not defined. Similarly, even if B.CPP files and A.CPP is a project, the file is used in the beginning of the Getch () in this file, it is written on the beginning of B.CPP: #include When the compiler compiles A.cpp, the compiler must compile CONIO.H once, and then compile the cono.h when compiling B.CPP. Therefore, once A.CPP introduces more headers as B.CPP, the compiler will waste a lot of time on the same header file. For example, if there is ten CPP files in our Project to introduce the same header gear, it means that the compiled time has 9/10 because it is wasted because it is used to compile the same header gear. Therefore, BCB introduces Pre-Compiled Headers technology, mainly to solve this problem that the compiler will make more repetitive compilation work, resulting in a long problem. The so-called pre-compiled headers technology, in the memory of the author, the concept of introducing from BCB 3.0, in fact, is very simple, it means "pre-compiling the header file". In the case of the example we just mentioned, the compiler will compile A.CPP, it will first "cache" first because of the use of Pre-Compiled Headers technology, first "cache" first, then wait until When compiling B.CPP, the compiler will find that Conio.h has been compiled first, so the compiler directly takes the results of the conoe.h that just get up directly, so that it will save it. A large number of compile time, while the programming designer can say by this to the lengthy compilation process bye Bye. In BCB, Pre-Compiled Headers technology is achieved through the compiler command #pragma hdrstop, known from the Help of BCB, and the header file before this compiler command will inform the compiler to use pre- Compiled Headers technology to speed up compilation. But things don't have our idea, so the author will spend a long space to explore the impact of compiler command #pragma HDRSTOP to compile performance.

First, we will delete all files generated in the compilation process in accordance with the mentioned in the , please note that * .tds must be turned off. After the entire project, please delete the * .csm and *. # ??, "?" Representatives in the lib sub-directory in the directory where the BCB is located. Next, we have a simple test with a clean program original code (that is, the original code has not yet compiled), the following data is based on the author's computer output result, the author's computer is equipped with: Intel PIII 450, Shengchuang PC100 128MB RAM, ASUS P2B motherboard, operating system is Windows 2000 Professional: program code 1: #include #include #pragma HDRStop # Pragma argsusedint main (int Argc) CHAR * argv []) {cout << "Hello World"; return 0;} Test results 1: Using Build Using Make Compiling Time Compiling Time Compiling Time Compiling Time Compiling Time 4192667.73 4192667.73 After the second time, 5106388.48 after the second time 0 0.14

Program Code 2: #pragma hdrstop # include #include #pragma argsusedint main (int Argc, char * argv []) {cout << "hello world"; returnography;} Part is different from the program code 1

Test results 2:

Using Build Using Make Compiling Time Compiling Time Compiling Time Compiling Time Compiling Ratinal Compile Time First 4192665.80 First 4192665.86 After the second time 5106384.42 After the second time, 00.15

Remind the reader, the blank line is also calculated that the compiler is in the compile line, so everyone may have some micro gaps on the compiling line.

The following conclusions can be obtained from the list:

For the two sets of test procedures, the compilation speed is almost different regardless of the MAKE or Build. But the second time after compilation, using Make's compilation speed overwhelming, and a lot is very fast, please readers should refer to some relevant books to introduce Make. Here, the author introduces O'Reilly (Taiwan Oujia) published by Managing Project With Make, this book seems to have a message that will appear in the website of Taiwan's Oura Gifts at www.oreilly.com.tw. Put the header file in the compiler command #pragma HDRSTOP, the time spent in the first compiler is longer than the compiler file in the compiler command #pragma hdrstop.咦? Before not mentioned using pre-compiled headers technology, it will speed up compilation speed. How do you find that the compilation speed is slower? To find the reason, we can use the Windows Start Menu Search / Archives or Data Clip Function, search the BCB directory, limit the search date to your computer's current date, readers can find that once you put the header file before the compiler command #pragma hdrstop, the lib sub-directory in the directory where the BCB is located. There will be two files of VCL50. # 00 and VCL50.csm, and the size of the file is quite big, but if the header file is placed behind the compiler command #pragma hdrstop, the two files do not appear (if the reader Test the program code 1 when testing, then test the program code 2, then the two files still appear, because the two files do not be deleted because of re-opening Project or re-opening BCB, so readers see It may be that the previously compiled VCL50. # 00 and VCL50.csm). In this way, we can boldly speculate: the reason why the header file is placed in the compiler command #pragma Hdrstop, the time spent in the first compilation is relatively long, because the compiler spends an extra Kung Fu to generate this Two files. Because the compilation time displayed after compiling is not only a simple compilation time, the connection time is also included to generate the time spent on the execution file. Accurately, it should be "From the start of compiling the original code to the final implementation of the final executive, the previous test data will give you a" use pre-compiled headers technology to slow compilation " Illness. The reader saw the data obtained from the test results 1, which is the author, except for the * .Obj, * .tds, * .Exe file generated when the author is deleted, except for the deletion of compilation, and except for the VCL50. # 00 And the two files of VCL50.CSM are measured. If the author does not delete the test program code 1 / use build, the data is generated by the data. # 00 and the VCL50.csm of the test result 1, the data will become: Test Result 3:

Using Build Using Make Compiling Time Compiling Time Compiling Time Compiling Time Compiling Ratinal Compile Time First 20172313.57 First 171.87 After 20172313.98 After the second time, 00.14

What is the reason is that the results are different? Because the author starts using the Build instruction to test compilation performance, then turn off the project, delete .Obj, .tds, .exe file generated during the compilation process, then re-open Project, Then use the Make instruction to test the compilation performance. At this time, due to the previous BUILD, the two files generated by the BUILD are still in the hard disk, so the compiler will be used directly when MAKE! We see that the compiler is only compiled 17 lines. From this, we can prove that the two files of VCL50. # 00 and VCL50.csm are our so-called cache files, and their role is to allow the compiler to reduce the number of compiled header files to accelerate compilation.

The conclusions obtained by the above, tell us that if we will do pre-compiled headers technology to compile the compilation efficiency assessment of compilation performance, you should use the build directive during the first compilation, and use Make after the second time. In order to accurately measure the improvement of Pre-Compiled Headers technology to compile performance, because we can see from the data, the Build instruction will make the compiler to recompile once from the head to the end, so you only look at Build The result is meaningless. However, it is inevitable that it is inevitable to recompile the entire system. For example, once we turn the program from the debug version into a release version, or turn the program from the release version into a debug version, then the first compiler, even if we use make to compile the program, the time spent in the compiler and uses Build The result of compilation is the same, all of which are heavy to the end and recompile. We can still use pre-compiled headers technology to make this compilation from beginning to tail faster, and will be mentioned later in this article.

The test program inside the previous paragraph has only one single program original file, then let's try if there are multiple programs original files in the Project. In order to avoid complication, we only test the situation of two program original files in Project. First, use File / New Add a unit:

And set the file into unit2.cpp. At this time, we have more files in our Project, which is Unit2.h and unit2.cpp, and their contents are as follows: program code 3: unit2.h # ifndef unit2h # define Unit2Hvoid test (void); # endifunit2.cpp # include #include #pragma hdrstop # include "unit2.h" void test (void) {printf ("test");} test results 4:

Compiling the number of compiled lines The first time (Build) 37556410.03 Second (Make) 00.16

We observed the lib directory under the directory of BCB. At this time, we will find that there are only two files before testing, and this test has more files, they are: vcl50.csm, vcl50. # 00, VCL50 . # 01.

Such test results do not seem to conclusions, so we have modified the contents of Unit2.cpp before the second compilation, before compiling, the content of Unit2.cpp is as follows:

Program code 4: #include

#include

#pragma HDRSTOP

#include "unit2.h"

Void test (void)

{

Printf ("test");

Printf ("test1");

}

The test results are changed:

Test results 5 (Test results 4):

Compiling the number of compiled lines The third time (Make) 301.19

This is the same as our expectations, and Pre-Compiled Headers technology exerts the ability to shorten the compilation time.

Later, the author added several Unit to test, prove that the BCB produced a VCL50. # ?? file (the premise here is: every Unit is introduced by each Unit) in addition to the VCL50.csm. The headers are different from each other. If the same words, there will be another case). If we have three Unit, he will generate VCL50. # 00, VCL50. # 01, VCL50 during the first Build. # 02, then add the VCL50.csm originally generated, there will be 4 cache files, so we can almost identify "Compiler will generate a cache file for each file that uses compiler command #pragma HDRStop. Upper compilation "" this we see the facts. That is, if we take the compiler instruction of Unit2.cpp, then the results measured after each time we modify unit2.cpp, it should be: Test results 6:

Compiling the number of compiled lines The third time (Make) 1738432.69

Instead of test results of the results 5 of the test results. Because there is no pre-compiled Cache file, Unit2.cpp must be compiled from the beginning to the end of the program.

Another test of the author is to use the compiler command #pragma hdrstop in unit2.cpp, then compile the execution file with the Make, let the compiler help us generate Unit2.cpp Cache files, the author does not delete any VCL50. # ??file. Then I took the compiler instruction in Unit2.cpp, although the changes of each original code will cause up to 173843, but after make a few times, if the author re-writer instruction #pragma HDRSTOP puts back in the original position in Unit2.cpp (that is, under #include below #include ), the result of compiling after each modification program is close to the test results 5.

Here we temporarily call the collection of all the introduced header files before the compiler command #pragma HDRSTOP, we boldly assume the compiler will help us record this tag in the cache file, Convenient the next compiler as an identification when compiling other files.

è Incident in a temporary conclusion based on the above assumption, the compiler is generally recompiled all header files every time the primary code is compiled. However, if the program raw file contains the compiler command #pragma hdrstop, the compiler will look for the VCL50. # ??, see if these files meet the current "pre-compiled tag", if complied, The compiler will directly collect the Cache left behind, so I save a lot of time to recompile the header file. If there is no Cache file that is in line with the mark, the compiler will still start compiling all header files. And after compiling, a cache file having the same "pre-compiled tag" in the original file, the next time the prior compiled tag of the program original file is the same, the compiler will be the same. Quote this cache file directly.

转载请注明原文地址:https://www.9cbs.com/read-30323.html

New Post(0)