The ccache tool improves the build performance by caching the incorporation of header files into source files and therefore speeds the build time by reducing the time required to add in header files with each compilation stage. In this article, learn how to build and install ccache, how to use it with your existing environment, and how to improve the build times in group development projects.
Improve collaborative build times with ccache
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
especially for builds where the headers are well predefined.
the bench marks seem a litle skewed though. won’t GCC only recompile a file if it has been modified? and won’t ccache have to recache a header file if its been modified?
so if i’m working on perl, and i make changes to foo.c, GCC won’t recompile everything, just foo.c and relink the whole thing. since perl has about a bagilion files, will ccache really do much if i only make changes to one file? and if i modify all the header files, won’t it be stuck in the same situation as compiling the first time?
I use a package called compilercache which does a similar thing.
http://www.erikyyy.de/compilercache/
Doesn’t GCC 3.4 already do header caching and such? What’s the big whoopdidoo?
They’re talking about how you can use it.
Like in distcompiling. 4node, hehe.. 250,000 node beowulf.
in that case, cache is like a spool, sorta.
there’s make switches you can add, frankenlinux had them years ago. the stuff rocks.
The author of that article completely misunderstood how ccache works. What he describes are “precompiled headers”. ccache will not save any time in the preprocessing (cpp) stage. It simply computes a hash of the cpp output (and some additional data like compiler version). It will even be slightly slower due to the hash computation. The savings come from skipping the actual compilation phase of the preprocessed source. If the same input (the preprocessed source) has been compiled before (matching hash) ccache will supply the cached object file directly instead of invoking the compilation phase.
This still saves a lot of time since preprocessing is a lot faster than the compilation.
How can a person write an article knowing nothing about how ccache works?
ccache stores in a directory the command line of the compiler, the *.o output of a compilation and the hash of the file. ccache calls the preprocessor obtaining a *.i file (preprocessed source) of the compiler and hashes it.
If the command is equal to a previous one and if the hash is equal to the stored one, it does not call the compiler, and the cached *.o is placed in the target. If the hash is not equal or it’s not present, ccache calls the compiler with the the preprocessed file, so no preprocessing is needed again. And ccache copies the target in the file cache.
In projects with a lot of rebuilds, saves A LOT of time, I use it at work and is VERY useful. If combined with distcc, is even better.
The IBM develeporworks articles and tutorials all have a feedback section at the bottom where you can select a radio button to rate the article and a text box for comments.
I’m sure that the author would revise the article if any of you were to point out his errors.
Done (to feedback form and authors email address).
Cool, MSVC has only had it since .. 1995 or so.
Maybe GCC will actually become useful? It’s really horrendously slow when you’re used to the blazing fast VC..
I’ve got a cygwin build environment here that I use to cross compile sources that will run on a sparc cpu. I installed ccache as per the articles instructions and added the ccache to my path. I also added cacche in front of my compiler definition… i.e. ccache sparc-elf-gcc as per the article.
The compile works fine however now when the linker is called to create a rel file the linker dies with a segmentation fault.
avfs.rel] Segmentation fault (core dumped)
(Attached below.) Of course when I remove the ccache definition the build operates just fine. Any advice from the guru’s out there?
Thanks
Matt
Exception: STATUS_ACCESS_VIOLATION at eip=0043D2F9
eax=00445950 ebx=00445890 ecx=0A01B298 edx=0000000D esi=0A01B338 edi=00000000
ebp=0022FCE4 esp=0022FCA8 program=c:cygnus100usp-99r1-elfinsparc-elf-ld.exe
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:
Frame Function Args
0022FCE4 0043D2F9 (0A01B298, 0000000D, 0A01B7E0, 0A01B298)
0022FDB4 004331CF (0A01B298, 00000000, 00000000, 0042E428)
0022FDF4 0042E4FD (0A01B298, 00000001, 0022FE30, 00412DAF)
0022FE34 004123D1 (0A0106D0, 0022FE7C, 0022FE84, 00412E2C)
0022FE84 00412E36 (0A0104C8, 00000000, 0022FEC4, 00415FF1)
0022FEC4 0041600B (00000004, 610AB3F0, 61133814, 61007988)
0022FEF4 00418DFC (0000001D, 6113C2CC, 0A010278, 00000000)
0022FF40 61005452 (00000000, 00000000, 00000000, 00000002)
0022FF70 61005746 (004187C8, 00000000, 0022FF90, 0046A811)
0022FF90 61005785 (00000000, 00000000, 00000001, 00000000)
0022FFB0 0046A742 (004187C8, 037F0009, 0022FFF0, 77E814C7)
0022FFC0 0040103C (00000000, 00000000, 7FFDF000, EF693CF0)
0022FFF0 77E814C7 (00401000, 00000000, 78746341, 00000020)
End of stack trace
Also note that you can deownload *much* faster linker (uld) on upp.sourceforge.net
so far, seems it works only for x86. it is part of “Ultimate++” IDE for Linux/Win
> Exxon Waldes (IP: —.139.212.194.contactel.net) – Posted on > 2004-08-29 12:07:52
> Also note that you can deownload *much* faster linker (uld) > on upp.sourceforge.net
> so far, seems it works only for x86. it is part of Ultimate++” IDE for Linux/Win
Wow, thanks man. Great tip! If you know some more of these development tools, please say so.
It’s really horrendously slow when you’re used to the blazing fast VC..
—
gcc is a compiler front for multiple languages which is supported on a huge number of operating systems and architectures. not even comparable