feat: cache.gz

[dkarlovi]

Closes #8679
Closes #8495

Benchmark

Gzip off

Cache folder size: 378M

# cache empty run
Checks took 20.86 seconds and used 808.750MB of memory

# cache primed run
Checks took 0.17 seconds and used 66.564MB of memory

Gzip on

Cache folder size: 47M

# cache empty run
Checks took 22.24 seconds and used 808.750MB of memory

# cache primed run
Checks took 0.66 seconds and used 74.394MB of memory

[dkarlovi]

@orklah @weirdan could you add a label to this PR so it's not spamming me with failures?

[dkarlovi]

Ready for review, the build passes but the label is missing and I don't know what Circle is on about, it's finding errors in code which doesn't exist, I can't reproduce it locally, composer cs passed cleanly for me.

[orklah]

Added the label :)

Please make sure to update your dependancies before running the CS fix, they improved detection a few versions ago, you may still be stuck with an old one

(anyway, the error is legit, you're missing a use function)

[dkarlovi]

I'm updated fully, this is a fresh checkout from today and I just tried to composer update -W, it's all up to date and cs-fix misses this. I've added it manually.

[dkarlovi]

@orklah green \o/

[orklah]

Should we put a config to opt in/out of gzip?

I get that cache size can be an issue for some situations, but runs on CI are likely more limited on CPU usage or memory usage rather than disk space, no?

[dkarlovi]

@orklah IMO the performance impact is negligible enough to allow this to be the default, you could opt out via config, but at 5% difference is it worth it?

[orklah]

Well, my work codebase make Psalm run with 8.5Gb of memory. Even 5% of that is not really negligible when I have to run it on my workstation

My specific example is not relevant because I can't even run cache at all (I have to disable it, otherwise Psalm never ends) but I think others may be in similar cases

[dkarlovi]

IMO it would make more sense to actually fix memory usage there instead of adding dozens of tiny tweaks in config.

[dkarlovi]

Quickly checked, the majority of memory spent when cache is not in use is by Psalm\Internal\Provider\StatementsProvider::parseStatements (65%) which in turn runs PHP Parser which itself eats most of the memory (50%). It's quite possible the memory doesn't get cleared properly here and usage always just increments.

The analyze step takes about 25% of memory. This is with cache disabled and a single thread.

[dkarlovi]

@orklah can you try what happens on your codebase if you reduce \Psalm\Internal\Provider\StatementsVolatileCache::__construct max size to 1?

I did and it went from

Checks took 24.80 seconds and used 808.879MB of memory

to

Checks took 22.30 seconds and used 675.669MB of memory

[orklah]

Discussion about memory is continuing on #9899.

If this change is causing performance issues in the future, we'll always be able to add a config then, I'll merge it as is for now

[kkmuffme]

@dkarlovi is there a specific reason igbinary unserialize errors are not suppressed?
https://github.com/vimeo/psalm/blob/master/src/Psalm/Internal/Cache.php#L54
https://github.com/vimeo/psalm/blob/master/src/Psalm/Internal/Cache.php#L57