Compliation Times
Author
This is a basic question that I probably should know. But why for large projects does C# compile faster than a C++ program? Could some one in the know tell me where they differ compile wise?
[Edited by - Balaam on July 13, 2007 4:37:00 AM]
there are LOTS of reasons
1. C# is a MUCH simpler language than C++, so given equal amounts of compiler writing skill and experience it should be much quicker in most cases (except C++ compiler writers have had more than 15 years to build better techniques for certain cases).
2. A C# compiler doesn't re-parse the header stream over and over, it just loads the meta data for all referenced assemblies, this is much more regular and simple to do. Precompiled headers in C++ can get this benefit too if properly organized and used.
3. C# output is only slightly optimized IL, a language very very similar in capabilites to C#, the JIT compilation of IL to native machine code happens later, when you first load an assembly on the running computer.
I'm sure there are more, but I have to go.
Good Luck.
1. C# is a MUCH simpler language than C++, so given equal amounts of compiler writing skill and experience it should be much quicker in most cases (except C++ compiler writers have had more than 15 years to build better techniques for certain cases).
2. A C# compiler doesn't re-parse the header stream over and over, it just loads the meta data for all referenced assemblies, this is much more regular and simple to do. Precompiled headers in C++ can get this benefit too if properly organized and used.
3. C# output is only slightly optimized IL, a language very very similar in capabilites to C#, the JIT compilation of IL to native machine code happens later, when you first load an assembly on the running computer.
I'm sure there are more, but I have to go.
Good Luck.
its mainly JIT. Never heard of C# being "much simpler language". IMHO would bet there are move native C# constucts than native C++ ones. I think C# is a easier to learn language
Quote:
Never heard of C# being "much simpler language"
It is somewhat simpler in terms of parsing; it is more well-defined in its structure and can make more contextual decisions automatically, et cetera. It's not really about the amount of native, built-in constructs, but the way in which they are defined and how they are allowed by the language to interact.
It does basically come down to the compilation model and parsing issues, though. C# is superior to C++ in pretty much all ways that affect compile times in that regard.
I agree with the previous writers that C# in some sense a simpler language considering compilation. Using Visual Studio and C#, the system (compiler driver) actually compiles the build all the time in the background on the fly. Eclipse, and NetBeans I believe, have gone similar route to speed-up the edit-compile-debug cycle. As why this is not done or is significantly slower in C++ enviroment than with C# in Visual Studio owes to the C++ build model as mandated in the C++ standard (for instance, in ISO/IEC 14882:1998(E)).
A number of issues contribute to the slow C++ builds. In very large code bases header file inclusion becomes a factor, since parsing through piles of text files inevitably creates overhead to the process. That is not the whole issue though, and in fact not even the main contributor to slow builds. I elaborate a bit on this issue and point out that there is an excellent resource available called Linkers & Loaders from John R. Levine. Also interested people can read issues regarding the new C++09 standard from Herb Sutter's homepage (from the paragraph labeled "Modules [N2073]".
So, to elaborate the C++ issues a bit further: C++ has a rather complicated naming and look-up scheme that contributes some time to builds (solved universally, in practice, by name mangling). Then there are global initialiser and constructor lists that have to be collected separately for special consideration. This takes some time also, since every module has to be checked for these. The most complex and time consuming issue, however, involves around templates. As you may have noticed, the build times easily sky-rockets with templates.
In times past the compiler driver actually did trial linking by first running through the whole compiling and linking phase enough many times recording and eking every round some new information to the final compilation phase. This is very time consuming and consequently the new drivers use a repository to which they record the necessary data. My knowledge is that compiler drivers today generally doesn't initially generate code for the templates at all, but do that on the second time when the compiler is re-run with the other compiler data.
One may wonder why there isn't a solution similar to that of C# with C++ in Visual Studio and the answer most probably is that due to C++ compilation model and complexity, it has been very difficult to achieve. Currently the Visual Studio team is reporting that they have a post-Orcas (Orcas + 1) plan to release an update to Visual Studio where C++ code is internally represented as Abstract Syntax Tree data structure, like is done with C#, for instance. This allows for incremental compilation, better IntelliSense support (you may have noticed that IntelliSense doesn't handle the entire C++ editing scheme gracefully) and code refactoring among other things.
A number of issues contribute to the slow C++ builds. In very large code bases header file inclusion becomes a factor, since parsing through piles of text files inevitably creates overhead to the process. That is not the whole issue though, and in fact not even the main contributor to slow builds. I elaborate a bit on this issue and point out that there is an excellent resource available called Linkers & Loaders from John R. Levine. Also interested people can read issues regarding the new C++09 standard from Herb Sutter's homepage (from the paragraph labeled "Modules [N2073]".
So, to elaborate the C++ issues a bit further: C++ has a rather complicated naming and look-up scheme that contributes some time to builds (solved universally, in practice, by name mangling). Then there are global initialiser and constructor lists that have to be collected separately for special consideration. This takes some time also, since every module has to be checked for these. The most complex and time consuming issue, however, involves around templates. As you may have noticed, the build times easily sky-rockets with templates.
In times past the compiler driver actually did trial linking by first running through the whole compiling and linking phase enough many times recording and eking every round some new information to the final compilation phase. This is very time consuming and consequently the new drivers use a repository to which they record the necessary data. My knowledge is that compiler drivers today generally doesn't initially generate code for the templates at all, but do that on the second time when the compiler is re-run with the other compiler data.
One may wonder why there isn't a solution similar to that of C# with C++ in Visual Studio and the answer most probably is that due to C++ compilation model and complexity, it has been very difficult to achieve. Currently the Visual Studio team is reporting that they have a post-Orcas (Orcas + 1) plan to release an update to Visual Studio where C++ code is internally represented as Abstract Syntax Tree data structure, like is done with C#, for instance. This allows for incremental compilation, better IntelliSense support (you may have noticed that IntelliSense doesn't handle the entire C++ editing scheme gracefully) and code refactoring among other things.
I adore the fast compilation times of Java code. A current project of mine consists of 154 classes, and a complete build takes less then one second.
EDIT: OK, it actually is a little more than one second, more like one and a half seconds.
[Edited by - DevFred on July 15, 2007 3:19:05 PM]
EDIT: OK, it actually is a little more than one second, more like one and a half seconds.
[Edited by - DevFred on July 15, 2007 3:19:05 PM]
Yes, or a complete re-compilation takes probably a whole lot more of time. That isn't just needed since the system is compiling on the fly in the background. :-)
Quote:Original post by Naurava kulkuri
Yes, or a complete re-compilation takes probably a whole lot more of time.
Yes, I am talking about a complete re-compile! Let me illustrate, here is a batch file I just wrote for testing:
@echo offdel /s *.classecho.echo compiled class files have been deletedecho.pauseecho.echo.|timeecho starting compilationecho.javac -cp c:\Programme\Java\jogl\lib\jogl.jar configuration/*.java counter/*.java effects/*.java eventing/*.java game/logic/*.java game/rendering/*.java gamestate/*.java globals/*.java heightfield/*.java input/*.java interfaces/*.java menu/*.java patterns/*.java physics/*.java startup/*.java tetraminos/*.java texture/*.java texture/t/*.java texture/uv/*.java util/*.javaecho finished compilationecho.|timeecho.dir /s *.classThis is the output it generates:
Datei wurde gelöscht - D:\src\configuration\Config.class[...shortened...]Datei wurde gelöscht - D:\src\util\Timer.classcompiled class files have been deletedDrücken Sie eine beliebige Taste . . .Aktuelle Zeit: 22:22:35,57Geben Sie die neue Zeit ein:starting compilationfinished compilationAktuelle Zeit: 22:22:36,93Geben Sie die neue Zeit ein: Volume in Laufwerk D: hat keine Bezeichnung. Volumeseriennummer: 541A-7565 Verzeichnis von D:\src\configuration15.07.2007 22:18 1.891 Config.class 1 Datei(en) 1.891 Bytes[...shortened...] Anzahl der angezeigten Dateien: 157 Datei(en) 200.950 Bytes 0 Verzeichnis(se), 52.488.884.224 Bytes freiI delete the class files and then manually compile all the java files from the console. There is no background build process, and it takes 1.36 seconds for 157 classes FROM SCRATCH! It really is that fast.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
