#needs profiling

> Is it possible there is something else causing the performance issues? ... Project Browser is by no means unusable, even with the slow status checks.

I agree it's within the bounds of being ok in "normal" circumstances. This is off course true, since no one thought it was a problem... One thing that slows things down is slow file I/O - there seems to be a lot of checks of the file system. What do you think that will be like with WebAssembly?

> the issue summary says we're running the status check on every page

I found that it was running when I was looking at project detail pages, which is most of the routes you can explore - did you not find this?

Btw. my main goal so far was to demonstrate for myself (and prove to others) that the browsing expereince was significantly improved with caching. So I'm not really wedded to *how* the caching should work and I was mainly waiting to see how the message improvemnet issue landed because it was calling the validation check.

Tagging for an issue summary update; the answers I'm asking for in #17 should be reproduced there.

Also, I need clarification on something: the issue summary says we're running the status check on every page, but I see no evidence of that? It's only run, as far as I can tell, by BrowserController, which is only invoked when you...load the project browser?

Is it possible there is something else causing the performance issues? Not saying it's necessarily bad to cache the results, because they certainly are expensive to compute, but I'm wondering how serious of a problem this actually is, and whether we're actually going to realize big performance gains across multiple routes by doing this. By no means is Project Browser unusable, even with the expensive status checks.

Tagging this for further profiling before commit, so we can be sure we're actually having a positive effect on performance by adding this cache layer.

Thanks for the guidance!

Before i forget, Chris wanted to be sure that this code was aligned with how AU/PM handles caching of this same data.

Package Manager doesn't do any caching; it only provides the infrastructure for doing status checks (StatusCheckTrait).

Automatic Updates has a StatusChecker service which, similar to InstallReadiness, wraps around StatusCheckTrait and caches the results in non-volatile key-value storage.

I propose that InstallReadiness do something like what StatusChecker does, but we should use a volatile cache bin instead of non-volatile storage. I think it's okay if status check results get wiped out on an unpredictable basis. The reason that AU uses non-volatile storage is because it's supposed to run in the background and needs to periodically check if it's still in a usable state. Project Browser, on the other hand, has no background presence; it's always something someone is actively using. So, volatile cache is okay for that.

Before i forget, Chris wanted to be sure that this code was aligned with how AU/PM handles caching of this same data. That was going to be something I looked at after 📌 Do not prevent UI install for PM warnings Needs review .

I'm generally in agreement here that it makes sense to cache the status check results for about 30 minutes, and certainly we'd want to clear them when a Project Browser install stage has been applied (PostApplyEvent).