FEAT Less cache fragmentation in ClassManifest

[lekoala]

Description

Reduce cache fragmentation by having only one entry for all cached files

Manual testing steps

Check number of files being created

BEFORE: 2k files

AFTER: 3 files

Issues

#11525

Questions

Should this target 6 ? for me, while this is technically a new "feature" it has only upsides and also "fixes" a performance issue

Pull request checklist

• The target branch is correct
  • See picking the right version
• All commits are relevant to the purpose of the PR (e.g. no debug statements, unrelated refactoring, or arbitrary linting)
  • Small amounts of additional linting are usually okay, but if it makes it hard to concentrate on the relevant changes, ask for the unrelated changes to be reverted, and submitted as a separate PR.
• The commit messages follow our commit message guidelines
• The PR follows our contribution guidelines
• Code changes follow our coding conventions
• This change is covered with tests (or tests aren't necessary for this change)
• Any relevant User Help/Developer documentation is updated; for impactful changes, information is added to the changelog for the intended release
• CI is green

[GuySartorelli]

Can you please throw some benchmark numbers at me to help understand what the actual performance impact of this change is (either in terms of time or memory)?

[lekoala]

@GuySartorelli sure (that made me realize i was missing a line in my code^^)

This is on a blank install on my machine (the files are stored on a regular hard drive, not a ssd, so that doesn't help and make the differences much more obvious)

Without cache folder already created (initial warm up, or if clearing the whole cache directory)

manifest:
Time: 8s
Peak memory: 16.000Mb
Memory: 16.00Mb

improved_manifest:
Time: 1s
Peak memory: 16.000Mb
Memory: 16.00Mb

With the cache already in place (and the enums fix applied, see my other PR, otherwise cache is not used)

manifest:
Time: 619ms
Peak memory: 6.000Mb
Memory: 6.00Mb

improved_manifest:
Time: 417ms
Peak memory: 6.000Mb
Memory: 6.00Mb

With no surprise, creating hundreds of files on the hard drive takes a substantial amount of time on the first run. Having a in memory array also helps a lot. This comes at almost no performance cost since the whole "manifest" array end up loaded anyway, and it's larger than the file cache.

This could certainly be improved even more (i don't see the need of having a separate file cache, the whole thing could fit in the same array) and the array could be optimized to avoid storing empty entries (which is, let's face it, most of it!)

[GuySartorelli]

Seems very sensible, and thanks for the benchmark, makes it clear that this is a worthwhile improvement.
Just a small change to make.

This could certainly be improved even more (i don't see the need of having a separate file cache, the whole thing could fit in the same array) and the array could be optimized to avoid storing empty entries (which is, let's face it, most of it!)

That sounds like it'd be a good idea - but probably worth doing as a separate PR so this one doesn't end up getting blocked.

[GuySartorelli]

LGTM, I'll fix the commit message on merge.
Thanks!

[mooror]

That sounds like it'd be a good idea - but probably worth doing as a separate PR so this one doesn't end up getting blocked.

I have to say I appreciate this ☀️. In different projects I have seen really good PRs just sit in the queue because an optional enhancement was requested and then the PR author got busy and it was never "finished", even though the PR by itself introduced great changes. So I appreciated the way you encouraged a separate PR for the optional change @GuySartorelli

Great feature/enhancement PRs @lekoala! Thank you for your work