Zadeh Tux's lil' helper
Joined: 31 Oct 2002 Posts: 131
|
Posted: Sun Dec 29, 2002 12:37 am Post subject: ccache not a very big win for most users. |
|
|
After noticing that I have thousands of files in cache and less than 1% of them are ever re-used, I noticed that ccache does not properly recognize files if their location is changed.
To test, just go into some source tree and do:
> time make
> make clean; time make
You will see a drastic speedup. However, if you move the tree and try to recompile, like e.g.:
> mv name-of-source-tree-dir /tmp
> cd /tmp/name-of-source-tree-dir
> make clean; time make
It will take just as long as it did to build it the first time for a lot of the bigger trees like e.g. Linux, X, KDE. So when portage spends hours and hours and hours building one version of a large package, say "foo-1.2.3r0" with ccache installed and then "foo-1.2.4" is released, a new temp directory for building the new version is made and it appears that typically very few of your cached files are re-used.
As an example: on my dual PII-based system it takes about 2minutes to rebuild my 2.4.19-gentoo-sources-r10 kernel tree if it is cached, but if I move it somewhere else and try rebuilding it, the time goes up to 10+minutes.
The result of having ccache on for the last month or so while tracking stable has garnered these (unimpressive) stats where most of the compiling was done by "emerge <package>" or "emerge -u world":
Code: |
# ccache -s
cache hit 1267
cache miss 33552
|
My guess is that since ccache uses the command line options as part of what it uses to determine the uniqueness of an input, it gets thrown off easily by small but semantically equivalent changes. For one, 'make' often generates a different path argument to a source file (absolute versus relative) when source trees move.
For e.x. when building the linux kernel, you'd see a lot of stuff like "-I/usr/src/linux-2.4.19-gentoo-r10/include" in the arguments passed to gcc, but when you move the tree that path changes - and to ccache, it considers it to be a completely different "input."
The same applies when portage constructs a new dir to build a newer version of a package - the path changes and so most (if not all) of your caching may for naught.
That I even got as many as 1267 cache hits is probably an anomoly from a statistical point of view compared to a "typical" user since I've re-built many of the same trees before. |
|