[ccache] [RFC] Do manifest_put in a background task.
ams at codesourcery.com
Fri Dec 14 09:08:33 MST 2012
On further inspection, I think this is unsafe: if the source files are
overwritten after the foreground task exits, but before the background
task hashes the file, then the result can be hashed incorrectly.
Unfortunately, this sort of thing happens quite commonly in autoconf tests.
I think I'm going to have to withdraw the suggestion, at least until
I've looked at it more closely.
On 20/11/12 21:51, Andrew Stubbs wrote:
> Hi all,
> This isn't meant to be a final patch, but more of a starting point up
> for discussion. Before it's a finished patch it'll need some autoconf
> work, some adjustment to the test-cases, and probably a config option to
> turn it off. (Another question is whether to do it on cache miss, as in
> the patch, or in all cases to take the stats update into the background?)
> The idea is simple: don't spend foreground time doing work that isn't on
> the critical path.
> My profiling (using valgrind --tool=callgrind) suggests that ccache
> spends approximately 10% of its run time running manifest_put, and this
> happens *after* ccache has already acquired all the results the calling
> build needs to continue.
> The time isn't wasted, it's an investment in the future, but it's still
> slowing down the current build, and a build with cache-misses is already
> a slow build.
> I've done some basic wall-clock benchmarking, and without this patch
> binutils 2.22 takes 2m:39s to build with an empty cache, on my machine,
> compared to 2m:25s if I use this patch. (The measurements were not
> terribly scientific, and repeated runs gave fairly noisy results, but
> those times are fairly representative.)
> In addition to just being nice-to-have on its own, this might also open
> up some previously-too-expensive possibilities for fixing the flaws in
> direct-mode caching, or even making improvements.
> ccache mailing list
> ccache at lists.samba.org
More information about the ccache