Years ago, I've used procmon.exe and saw VB6 load project files by doing tons of 1 byte reads...
I wonder if the behavior in the article also applies to C# compiles?
I wonder if the behavior in the article also applies to C# compiles?
C# compilation is seriously fast compared to C++ and the likes (due to its proper staticly typed nature) and this allows the compiler to assert certain things quickly and not waste any more time on this.
Given how .NET developers loves separating things into tons of DLLs and libraries (and how .NET makes this easy), I would be surprised if this part of the compilation wasn't as optimized as the rest of the process.
I'm not sure what you mean by this - C++ compilation isn't slow because of a lack of static typing :)
Here is some actual info on the subject: http://www.drdobbs.com/cpp/c-compilation-speed/228701711
Go is fast to compile as well and statically typed
See the post on the C++ preprocessor that was on HN some days ago as well
"The core tenant of C++ has been to move work from runtime to to compile time."
Both RAII (avoiding use of new & delete) and generics are strengths of C++ but also require heavy compile time work.
RAII needs decent analysis and optimization or your program will thrash copying struts by value. Generics and templates force your compiler to run a second compilation in your frontend.
This on top of C's copy/paste based include system and macros gives you what should be one of the slowest to compile procedural languages designable.
That's what I thought anyway?
C++ compilation is sort of screwy in that to compile a new C++ file the compiler actually has re-compile all the definitions of the libraries you are using. It is insanely inefficient compared to just using explicitly defined and immutable API interfaces on Assemblies/Modules.
Right now the closest thing is FxCop or a third-party tool.