lazily decode cache files for checking invalidation

[gbaz]

This yields a significant (15% ?) speedup on rebuilding build plans for projects with lots of individual cabal packages. (As in https://github.com/peterbecich/cabal-resolver-issue which is a repro for #7466). In such cases the cache files can grow quite large (up to approx 30M).

The way the old filemonitor / caching system worked, it would first read and fully parse each cache file, and then check it to see if it was invalidated (an operation that only involved the header portion at the beginning of the file). When files are small, the full parse isn't noticeable. But as files grow large, this parse can become quite expensive.

This changes the deserialization to go in two steps -- first parse the header info, and check for invalidation. Then, only if the cache is valid, proceed to deserialize the remaining (potentially large) serialized value. Testing reveals that this removes deserialization as a noticeable cost center immediately -- dropping it to about 3% of total time.

(note: the writing out of the cache files is still about 10% of total time, but that seems fairly unavoidable)

[fgaz]

Thanks!

[gbaz]

The failure is because the binary 7.6.3 ships with doesn't export runGetOrFail or any other incremental method I can see :-/

cf: https://downloads.haskell.org/~ghc/7.6.3/docs/html/libraries/binary-0.5.1.1/Data-Binary-Get.html

Any suggestions the best way to deal with this?

[gbaz]

Oh, hrm. It has an incremental function runGetState but just no functions that don't throw on error... I suppose I can try to make do with that.

[fgaz]

You could move structuredDecodeTriple to cabal-install, which does not support ghc 7.6

[gbaz]

Great suggestion @fgaz, done!

[Mikolaj]

I wonder if writing out of the cache files can be done on a separate (low priority) thread top speed things up.

[Mikolaj]

I've bitched about whitespace, but otherwise it looks great.

[gbaz]

I wonder if writing out of the cache files can be done on a separate (low priority) thread top speed things up.

I thought about that too. We don't really use separate threads for IO ops elsewhere in cabal afaik, so I didn't know about setting a precedent. I'd think we'd need some slightly careful architecture to make sure that reading and writing didn't step on one another, etc., so not sure about the tradeoff between complexity and a constant win in some large cases.

[Mikolaj]

Yes, also, a user trying to exit before writing is finished, while otherwise cabal seems to have done it's job and is just hanging, would deserve a warning and a confirmation, which again adds to complexity of the solution.

If cabal always keeps its caches in memory and so never reads caches that it writes in the same session, that would simplify things. OTOH, this makes cabal use more memory than it would otherwise.

BTW, the CI broke on some timeout, so I'd ignore it. (edit: and merge)

[emilypi]

@Mergifyio backport 3.6

[mergify]

Command backport 3.6: success

Backports have been created

• #7537 lazily decode cache files for checking invalidation (backport #7516) has been created for branch 3.6