3 ms·
I'm going to assume you mean that when you update a project, it takes a long time to recompile-- as opposed to the time it takes to compile from scratch (althou
by dmlorenzetti 15y ago
I'm going to assume you mean that when you update a project, it takes a long time to recompile-- as opposed to the time it takes to compile from scratch (although I would still be surprised if Java is faster on a comparable-sized project).
You may have an include file that gets touched/changed a lot, and that shows up (directly or indirectly) in most of your project files. Have a look at your dependency tree and see if anything jumps out at you. Alternately, you can "touch" a few files at a time manually, re-build, and try to track down a culprit that way.
Also, take a look at John Lakos' "Large-Scale C++ Software Design", which offers metrics and design guides for reducing dependencies among files in a project.
Assuming you have no way to get around each source file including lots of headers, many C/C++ build tools offer some kind of "pre-compiled header" option, that you might look into.
Finally, check to see whether you're doing a very aggressive "release" build, with lots of inter-procedural optimizations enabled. I find IPO at the link stage takes a very long time. So compare your debug build options against your release build options, and think about what the timing differences tell you.
- karussell 15y ago> although I would still be surprised if Java is faster on a comparable-sized project Presumable I should really do a side by side comparison for a project of the same LOC but I always had the subjective feeling > You may have an include file that gets touched/changed a lot I more meant an initial clean&compile step > "pre-compiled header" option what do you mean here? > Finally, check to see whether you're doing a very aggressive "release" build, ok, this could be one cause, yes
- dmlorenzetti 15y agowhat do you mean here? ("pre-compiled header") I don't know all the details, but consider that the compiler has to read the header file, parse it, make a map of its contents (its declarations and #defines and type definitions and so forth). And it has to do that over and over, for every source file that includes that header. So if the compiler stashes away a binary representation of the contents of that header, then it can skip the slow bits of reading the text file and figuring out its contents and all. It only has to do that the next time you change the header. edit: See http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html Java, I believe, essentially does this already, because it turns each .java file into a .class file (or whatever, it's been a while). And that .class file contains all the information that other java sources need in order to know what's in that java file. Fortran-90, a language that gets no love on Hacker News, has a nice module facility that also enables this. Module information can get stored in a binary form that other sources can look into without having to re-parse the original text file. Going back to C/C++, though-- if your root problem is that you have big header files that appear everywhere and slow down the compilation of every module, then you may want to think about reorganizing your code to reduce dependencies. Pre-compiling the headers may remove one of your symptoms, but not the real cause of the problem.
- karussell 15y agoThanks for your explanation!
- jason_slack 15y agoI have: John Lakos' "Large-Scale C++ Software Design" Free to anyone that will cover the shipping cost. Glad to see if goto a good home.