Files
Files copied to clipboard
files-community
Save folder index size
What's the Problem?
When ever I refresh or go back and forth a directory with folder sizes enable they get re index every time (no idea if this causes unnesary drive usage). Side note it doesn't seem to use the properties way so when opening the properties of that folder it also re index's the size.
Solution/Idea
Cache the folder size (for properties and item column) and refresh with content changes.
Alternatives
None
Priorities
No response
Files Version
No response
Windows Version
No response
Comments
No response
I already tried. It is easy to cache the size of each calculated folder. The calculation is recursive therefore the subfolders are already cached when we open them. For this functionality, it is necessary to delete the cache of a folder when it is updated, even when it is not displayed. Technically this is possible, but it seems to me that it is not yet used by Files. I don't know the impact on performance. I'll investigate.
I already tried. It is easy to cache the size of each calculated folder. The calculation is recursive therefore the subfolders are already cached when we open them. For this functionality, it is necessary to delete the cache of a folder when it is updated, even when it is not displayed. Technically this is possible, but it seems to me that it is not yet used by Files. I don't know the impact on performance. I'll investigate.
Seems like it can be a bit heavy but I think it should be fine if we indicate that in the setting description.
@yaichenbaum Here is an idea for improvement that can be implemented quickly and easily, while waiting for a more complete solution.
- When we want to display the size of a folder, we check if the size is cached. If so, we display it, otherwise we display a message (Calculation in progress ...).
- Then, we calculate asynchronously and recursively the current size of the file, because it could have changed.
- During recursive computation, the size of the sub-folders is cached, being limited to 2 levels so as not to overload the memory.
- When the calculation is finished, we update the cache and the display.
- If the cache is too large, the oldest datas are deleted.
This will faster display the values already calculated (the same folder or subfolders), and update the value if it has changed.
@yaichenbaum Here is an idea for improvement that can be implemented quickly and easily, while waiting for a more complete solution.
- When we want to display the size of a folder, we check if the size is cached. If so, we display it, otherwise we display a message (Calculation in progress ...).
- Then, we calculate asynchronously and recursively the current size of the file, because it could have changed.
- During recursive computation, the size of the sub-folders is cached, being limited to 2 levels so as not to overload the memory.
- When the calculation is finished, we update the cache and the display.
- If the cache is too large, the oldest datas are deleted.
This will faster display the values already calculated (the same folder or subfolders), and update the value if it has changed.
Is the cache you're talking about going to be stored across app sessions or only for the current instance?
@yaichenbaum To improve the idea above, we can update the cache directly when adding/removing files with Files by impacting the size of the parents in the cache. This will make it possible to have the right size immediately after an operation in Files, when we return to the parent.
@yaichenbaum I think limiting the cache to the current instance is sufficient. Storing the info in a db will pose too much of a performance and update problem, for very little benefit. You can always add it later if needed.
@yaichenbaum I think limiting the cache to the current instance is sufficient. Storing the info in a db will pose too much of a performance and update problem, for very little benefit. You can always add it later if needed.
I think it's worth keeping it across sessions because otherwise, it won't make much of a difference.
@yaichenbaum The problem with a persistent cache is that drives can change paths. In uwp, it is not possible to have the volume guid. I will do a version without persistence, but with an update during the session. The sizes of subfolders are already calculated during the parent folder. We will add persistence later if possible.
@yaichenbaum I tried but failed. All my attempts only got nulls. I may have missed something. If someone can get a unique id for a volume, we might have something really cool. I started working on the file size cache again, because the searchpanel needs integration #7892. I already have a cache system and it's very nice. I need to improve it to optimize memory usage before publishing it.
Appears to have been fixed with #7960
@duke7553 the cache in #7960 is only a temp cache.