On 7 July 2015 at 10:58, Andrew Stubbs <a...@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 _______________________________________________ ccache mailing list ccache@lists.samba.org https://lists.samba.org/mailman/listinfo/ccache
