Do and automate performance testing about composer-stager

[TravisCarden]

Thanks for the thoughts, @wimleers. Let's save them for later. Those issues were explicitly deferred to follow-ups "if our testing shows we need it". Per the issue title and proposal, this is scoped at getting some initial performance data and automating ongoing scans.

[wimleers]

Cache filesystem scan results for reuse between preconditions within the same PHP process.

Is this necessary? That'd cause significant increase in memory consumption, and it'd increase linearly with the complexity of the site (i.e. more packages = more files) 😅

Isn't the fact that stat() (and lstat()) is cached already enough? See the clearstatcache() docs for details.

I think a single clearstatcache() prior to evaluating the children of NoUnsupportedLinksExist would be sufficient to guarantee up-to-date results at all times?

Cache whole precondition check results beyond single PHP processes, with cache expiration/invalidation.

Not only would this be a huge amount of complexity to manage … but how could this possibly handle cache invalidation? You'd have to rely on inotify on Linux, FSEvents on macOS etc. (I know because I once built something on top of these: https://github.com/wimleers/fileconveyor.)

Run precondition checks concurrently, i.e., multithreaded.

Did PHP add multithreading support I do not know about? 😅

[TravisCarden]

Adding this as a prerequisite for https://github.com/php-tuf/composer-stager/milestone/1 per @effulgentsia

[wimleers]

Why was this removed from the v2.0.0 milestone on March 21? (I'd like to understand the rationale.)

[effulgentsia]

The thinking was that even if some refactoring of the preconditions ends up being needed that it can be done without breaking APIs, so could be done in 2.1 or 2.2.