Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FEAT Less cache fragmentation in ClassManifest #11533

Open
wants to merge 2 commits into
base: 5.3
Choose a base branch
from

Conversation

lekoala
Copy link
Contributor

@lekoala lekoala commented Jan 7, 2025

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
image

AFTER: 3 files
image

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
  • 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

@lekoala lekoala changed the title FEAT less cache fragmentation FEAT Less cache fragmentation in ClassManifest Jan 7, 2025
@GuySartorelli
Copy link
Member

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
Copy link
Contributor Author

lekoala commented Jan 10, 2025

@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!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants