Bootsnap was initially designed for improving boot time in development, so it was logical to use mtime to detect changes given that's reliable on a given machine.
But is just as useful on production and CI environments, however there its hit rate can vary a lot because depending on how the source code and caches are saved and restored, many if not all mtime will have changed.
To improve this, we can first try to revalidate using the mtime, and if it fails, fallback to compare a digest of the file content. Digesting a file, even with fnv1a_64 is of course an overhead, but the assumption is that true misses should be relatively rare and that digesting the file will always be faster than compiling it. So even if it only improve the hit rate marginally, it should be faster overall.
Also we only recompute the digest if the file mtime changed, but its size remained the same, which should discard the overwhelming majority of legitimate source file changes.
Ref: https://github.com/Shopify/bootsnap/issues/336
Bootsnap was initially designed for improving boot time in development, so it was logical to use
mtimeto detect changes given that's reliable on a given machine.But is just as useful on production and CI environments, however there its hit rate can vary a lot because depending on how the source code and caches are saved and restored, many if not all
mtimewill have changed.To improve this, we can first try to revalidate using the
mtime, and if it fails, fallback to compare a digest of the file content. Digesting a file, even withfnv1a_64is of course an overhead, but the assumption is that true misses should be relatively rare and that digesting the file will always be faster than compiling it. So even if it only improve the hit rate marginally, it should be faster overall.Also we only recompute the digest if the file mtime changed, but its size remained the same, which should discard the overwhelming majority of legitimate source file changes.