Folder size and Caching

[LittleBiG]

Why not just the first subfolder(s) of the current folder to cache (without any further recursion)?

Yep, exactly what I will do.

Do you have a logical explanation to do so? I still can't see the advantage. Please think about it a bit more:
Base situation: recalculating the size of Downloads folder.
1. Your solution: calculating the size of Downloads (x seconds) and calculating the Downloads/SubfoldersFirstLevel (y seconds). The necessary amount of time is x+y.
2. My solution: delete the subfolders from cache (to be comparable with your solution, only the 1st level of subfolders to remove) then calculating Downloads folder. Calculation time is only x. When I go into a subfolder, that will be missing from the cache, so the calculation time will be y/TotalNumberOfFolders.

What I don't undertsand: why is it better to wait for the process longer to finish 1 time, than to do it in smaller parts, and do the calculation when and if it is really necessary?? Maybe I will never enter a subfolder in the Downloads, but it was calculated and increases the cache. I don't have SSD, so the calculation difference can be significant.

It is similar in some way to the Custom Column trigger. Your solution is the "Browse", mine is the "List".

[admin]

1. Your solution: calculating the size of Downloads (x seconds) and calculating the Downloads/SubfoldersFirstLevel (y seconds). The necessary amount of time is x+y.

This is a wrong assumption. The time is x + nothing, since all levels have to be calculated anyway to get the size of Downloads.

[LittleBiG]

1. Your solution: calculating the size of Downloads (x seconds) and calculating the Downloads/SubfoldersFirstLevel (y seconds). The necessary amount of time is x+y.

This is a wrong assumption. The time is x + nothing, since all levels have to be calculated anyway to get the size of Downloads.

I seeeee now. My solution needs calculations later, yours doesn't. Yours can cause bigger database which should be tamed by this 1 level limit. Yours is really better, until accessing the cache takes longer. So, then yours seems ok to me too, thanks.

[DmFedorov]

Why not just the first subfolder(s) of the current folder to cache (without any further recursion)?

Yep, exactly what I will do.

I don't understand this decision.

At first I offered to show the cache instead of calculation (if size was calculated) for very large folders (in which the number of elements is greater than a my number).
It is clear to me. All other folders will be calculated.

Can you explain what advantage gives the cache entry for first-level subfolders?
If it is any current folder, then the first it subfolder can be very small, and, theoretically, the largest may be any (last) level of subfolders.

[neil9090]

Love the feature addition Don.

Am I doing something wrong in 16.80?
So I have turned on caching, if I move into a sub folder delete or add new files etc... why does the caching not get invalidated for the folder.
i.e. C:\folder\subfolder (2 files)
delete files from the subfolder
move up a level to the C:\folder
XY doesn't set/unset the flag to refresh the cache the next time it visits the parent folder C:\folder

Doing a similar thing in reverse, the cache says that the folder is empty, then if you create, a file or subfolder.
Revisit the parent folder and it still is cached as empty.

Workaround CTRL-F5 to reset the cache.

Just some other thoughts;
Tweak/Option to refresh list/folder and folder sizes all in one.

Could there be a Tools \ Customize List \
Show Real Folder Sizes (for SSD disks or folders with small counts in other words won't really slow up folder browsing)
Show Cached Folder Sizes (used for larger folders or network shares etc.)

re the "date of poll in UTC"
When comparing a folder against the last poll date could there be an option per folder setting; Cache expiry setting i.e. 0 minutes/hours/days/weeks/months/years
Some folders you want in effect live info, others don't really change thus could be set higher.

[admin]

Why not just the first subfolder(s) of the current folder to cache (without any further recursion)?

Yep, exactly what I will do.

I don't understand this decision.

At first I offered to show the cache instead of calculation (if size was calculated) for very large folders (in which the number of elements is greater than a my number).
It is clear to me. All other folders will be calculated.

Can you explain what advantage gives the cache entry for first-level subfolders?
If it is any current folder, then the first it subfolder can be very small, and, theoretically, the largest may be any (last) level of subfolders.

Sure, it's just one idea to limit the size of the cache.

I have another idea: we could use size or number of items, independently of the level: So, e.g., cache all subfolders with more than 100 items. Hm? Probably better!

[bdeshi]

I have another idea: we could use size or number of items

Or folders with really old modified/accessed dates, as they're more likely to remain unchanged.

[DmFedorov]

Sure, it's just one idea to limit the size of the cache.

I have another idea: we could use size or number of items, independently of the level: So, e.g., cache all subfolders with more than 100 items. Hm? Probably better!

OK. I understood. It's another... Although it seems to me that the size of the database is irrelevant. It will not be more than 10 MB. The main thing - quickly and that these 10MB were not always in RAM.
Of course, if you believe that it is necessary to reduce the data base, do it.
-------
But my suggestion is still in force? I suggested that all folders (with recursion) that have a number of elements more e.g. than 5000 will be display in the form of cache only (no calculating).

[DmFedorov]

I have another idea: we could use size or number of items

Or folders with really old modified/accessed dates, as they're more likely to remain unchanged.

I recently did a test: I took the file and have reduced its size. The name remained the same. Date of the folder was not changed.

[Filehero]

I have another idea: we could use size or number of items, independently of the level: So, e.g., cache all subfolders with more than 100 items. Hm? Probably better!

Sounds better to me. The number would be a config item, right?

I'm still thinking about a feasible way for my cache-locations-white-list. For obvious reasons it's quite ugly to use the current (global cache-on plus) tweak for reversion of logic (though it's a common XY pattern), something like

Code: Select all

CacheFolderSizesExclude=!D:\FolderToCacheFolderSize

Actually, I quite like DmFedorov's idea of having the (tab headers) config being part of a FVS.

But yes, an item number combined with a visual clue (~, or a distinct foreground color ) would be welcome.

[LittleBiG]

Additionally, I wouldn't cache the [Empty] folders. It will be very misleading when some file will be added and the cache still shows empty. It is worse than a not quite exact folder size.

I would like to bring this to your attention with the addition that zero size also shouldn't be cached. I have just unzipped something into a new folder. Its size was cached 0 (because WinZip created the folder first than started to fill with the data), however I unzipped more than a gigabyte into that folder...

Good idea! Done.

Thanks! Would be good for zero too. Here is my folder immediately after extracting:

[admin]

OK, right.

[LittleBiG]

If there are folders with the same name on more portable drives, and they are used one after other getting the same drive letter, folder size caching gives you a very strange result. I was shocked when I first saw the size of my E:\Books and E:\Movies folders on a pendrive. Then I saw the "~" and did the math.

[admin]

If there are folders with the same name on more portable drives, and they are used one after other getting the same drive letter, folder size caching gives you a very strange result. I was shocked when I first saw the size of my E:\Books and E:\Movies folders on a pendrive. Then I saw the "~" and did the math.

OK, maybe I should disable FCS on removables? Yes, probably...

[LittleBiG]

Maybe supporting the volume label here in case of removables could do some good... But I know you want to keep it simple for now. Just take a note about it for the time you want to improve it. Because now I am happy to know that I won't get any unpleasant surprise any more, but when I browse my 64 Gb pendrive, I miss the feature.