Tell me more ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.
up vote 9 down vote favorite

Since way before Mac OS X came on the scene, we have been able to ask the Finder to Calculate all sizes in order to determine the sum total of readable file size space contained in each folder for the Finder window in question.

Finder - list view - show view options - Calculate all sizes

I have tested List view sizing of folders on several Macs where it doesn't matter if an SSD is present or not, but Lion is so fast at calculating sizes I am curious if there is some new caching data structure or if Finder is using the metadata information from Spotlight or a similar database to speed up this calculation immensely.

share|improve this question
1  
Where did you get that window? Based on the "Use as Defaults" button at the bottom, it looks like the "Show View Options" window (<kbd>⌘J</kbd>), but I couldn't get anything to show in the bottom section. – CajunLuke Mar 28 '12 at 5:47
1  
@CajunLuke you need to switch your window view to list before opening the "Show View Options" window. – pdd Mar 28 '12 at 23:47

4 Answers

up vote 3 down vote accepted
+50

I have not observed Lion to be faster at calculating folder (and package/bundle) sizes during the first time it calculates sizes in a folder. However, subsequent calculations in the same folder do seem to be much faster.

Part of the perceived quickness may be that Finder will immediately show the previously calculated sizes in gray text while it recalculates folder sizes, rather than showing "--" until it's been calculated. After a folder's size has been recalculated, the number will update (if the size has changed) and turn black.

Because the Finder is observably caching previously calculated folder sizes, it's possible that it's only recalculating sizes for folders that have changed since the last time it was calculated.

share|improve this answer
I think this is the nub of the issue. Caching is much better and partial or stale results are displayed incrementally. I can't tell if the algorithm is tweaked to fill in the data that is in view, but the cacheing alone seems to be the answer to my pleasure with how it works in practice now. – bmike♦ Apr 2 '12 at 4:15
After some months of observing this closely, you are totally correct. The caching mechanism is now so good that on the Macs I have used for a while, this data is almost always correct and instantaneous. Only on a new mac shortly after reinstallation or confederation is the older speed noticeable since the OS has to collect the information entirely. – bmike♦ Jun 26 '12 at 16:09
up vote 5 down vote
+100

Before Lion, the File Size column in Finder.app would display the size each file requires on the hard disk, not the exact file size. For example, 1 byte files were displayed as 4 KB because they do in fact take up 4 KB of space on a HFS-formatted system. There was no easy way to see the actual file size of 1 byte, other than opening File › Get Info (or using a different app, like Terminal.app and then using ls -lsa, or a Finder.app replacement like TotalFinder.app).

(Back in the day, I reported this as bug 8926275 on bugreport.apple.com.)

As of Lion, this behavior has been corrected, and the File Size column will now show the exact file size for each file rather than the size it allocates on the hard disk (which depends on the file system anyway).

Since these sizes are the same numbers you’d get from the ls binary in Terminal, they’re much more efficient to calculate.

share|improve this answer
1  
This is awesome detail as well. As SSD become more prevalent and storage gets more sophisticated with snapshots, I suppose it's long past due to stop worrying about how much space a specific instance of a file is occupying and just worry about the logical size of files as opposed to the physical. – bmike♦ Jun 26 '12 at 16:12
I don't understand this. How is that more efficient? Isn't a single stat(2) call responsible for retrieving both numbers? And ls(1) doesn't show the actual size of bundles/packages/folders at all, so I have no idea why that's relevant. – Ken Jun 26 '12 at 22:16
@Ken ls shows file sizes just fine for regular files. stat can do the same for a single file. My point is that the “extra work” needed to calculate bundles/packages/folders sizes is now only needed for bundles/packages/folders, not for regular files anymore. – Mathias Bynens Jun 27 '12 at 7:18
Mathias: Yes, ls shows file sizes for regular files, not bundles (that's what I said). It does this by calling stat. What "extra work" was required for regular files previously? A single stat call returns both blocks (st_blocks) and bytes (st_size). – Ken Jun 27 '12 at 18:40
up vote 1 down vote

I wouldn't be surprised if they were using Spotlight metadata to cache file sizes. If you're already using FSEvents to track all changes in the file system and (potentially) Time Machine to back all those changes up, the added cost of calculating and storing aggregate file sizes is negligible.

share|improve this answer
I'll see if I can get fs_events to spill the beans if it's metadata or otherwise. I'd love it to read spotlight data - but don't have direct evidence yet. – bmike♦ Apr 2 '12 at 4:16
up vote 1 down vote

Starting with OS X Lion, Apple has added a SQLite database that the OS uses for file tracking in system features such as Spotlight. Querying from a SQLite database rather than inspecting the file system every time is more than likely the cause for the performance improvement. John Siracusa's OS X Lion review explains in depth the changes to the file system in Lion. Particularly, here you will find an explanation on the new SQLite database.

Hope this helps.

share|improve this answer
This is a very nice link, however the SQLite database appears on all my macs to only track documents that have versions which is a small subset of the total files on the drive. If you can find a link to a database that stores all file sizes, that would be interesting to say the least since the filesystem is already a database to do this, no? – bmike♦ Jun 27 '12 at 18:00

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.