[ccache] Caching failed compilations
Joel Rosdahl
joel at rosdahl.net
Wed Jul 8 15:04:53 CEST 2015
On 7 July 2015 at 10:58, Andrew Stubbs <ams at codesourcery.com> wrote:
> On 06/07/15 21:44, Joel Rosdahl wrote:
> > But maybe writing some special content to the object file would be OK?
>
> OK, fair enough, but I'd say that once you've opened the file and checked
> the magic data then you've already killed performance.
On a cache miss, the object file doesn't exist, so it doesn't need to be
opened. On a cache hit, we need to open and read the file regardless of
whether it's a real object file or special data encoding an exit code. In
what way would this kill performance?
> A failure can be confirmed by a read, if and only if the length matches,
but
> a compile success will remain on the quick path.
You lost me there. :-) I don't understand what you think would be a slow
path. Please expand on this.
To me it's simple: If we have a cache hit, we know the result and we have
to read it. If we have a cache miss, the result doesn't exist and we don't
have to (and can't) read it.
> OK, that's quite a lot of files. Hopefully it does not look for a file
unless it
> really ought to be there?
For the standard code paths, yes (barring bugs), but e.g. when doing
cleanup it has no information about which files to expect so it has to try
to delete all known file types for a given result.
> I worry that you'll hurt the common case (just two files) in order to help
> the uncommon case, and that that is already about as good as it can
> be (especially with hard-links).
A major part of the idea was to improve performance, not make it worse, so
no need to worry. If it's a bad idea for performance reasons it won't
happen.
-- Joel
More information about the ccache
mailing list