![]() So, I don't think it's a problem with APFS (although, it would be nice if someone did a similar test with HFS+), but it's the Finder. I believe (but have no verified) that this extra hash code, which may appear rather random, will order the file names not alphabetically because the hash code has precedence, but a lookup still should be doable in a binary search because once you know the name you want to look up, you also know its hash code. This combines three parts: The directory ID, a hash code of the file name and finally the file name itself ("j_drec_hashed_key_t"). That makes it slower than HFS in some situations (that's the main reason why you don't want to use APFS on hard disks, because of the double number of sector seek operations, which are quite noticable on a mechanical devices but not at all on an SSD).Īpart from that, the key for a tree node entry encodes not only the directory ID and the file name (which are ordered) but also some extra code for dealing with unicode intricacies. It uses two B-Trees, where one has pointers into the other. Insertion then is also rather fast because of the B-Tree's nodes, often only a single block back to disk. With that, an insertion would not need to scan ALL entries like Mike B suggested but can perform a binary search. With HFS, the directory would gather all files of a specific directory together in clusters, with the file/dir names ordered alphabetically. I wonder if APFS is when the listing got slow. ![]() Oddly, I don’t remember that being particularly bad with the prior single-file-per-message folder structure from 10.4. So it’s not all in one folder, but they should add multiple levels like with Mail if it doesn’t already do Yeah, Time Machine was the impetus, but it also helped with browsing the directories. I don’t understand why it is so slow to enumerate not-that-many entries compared with what my apps deal with using SQLite or their own file formats, but it I don’t have a lot in Photos so I don’t know how its library scales, but it seems to have one folder of originals per hex digit. That doesn’t seem like it should be more than linear, but I presume that somehow the higher layers are creating big lists of file records and copying them repeatedly or something. I’ve mostly noticed the slowness with listing a directory. Stuck When Upgrading Directly From macOS Mojave to Big SurĪpple File System (APFS) Apple Mail Carbon Copy Cloner Core Data Mac macOS 13 Ventura Optimization Spotlight Yeah, it seems like the B-Tree part in the filesystem shouldn’t care that much for lookups.If you navigate to the hidden Library folder in your home folder, then to Mail > V10 > Data, you’ll see folders named by number, four layers deep, until you finally get to a Messages folder with actual files in it.Īpple should also employ this technique for Core Data external storage and Spotlight temporary files. longer than 10 minutes) that the task aborts with an errorįor a contrasting example, consider how Mail organizes a potentially astronomic list of files. In extreme cases like this, the delay to retrieve a file list can be so long (i.e. In other words, more than 10% of the files on the whole startup disk were in that “media” folder. Upon closer analysis, we determined that the “media” folder had 181,274 files in it. ![]() Last week, one of our users found the task as shown above. ![]() Gathering the enormous file list will also take progressively longer as the list gets larger. Adding a new file, for example, requires that the filesystem compare the new item name to the name of every other file in the folder to check for conflicts, so trivial tasks like that will take progressively longer as the file count increases. Any time a folder has more than a few thousand items in it, the filesystem is going to be a lot slower when working with that folder. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |