Hacker News Reader

Comment by layer8 | Hacker News Reader

The problem isn’t counting the files (the algorithm in the article also counts the files), but that if you determine that you want to use the ith file only after counting all files, you have to iterate over the whole directory again (or over expected half of it) to find that file.

View on HN

The mechanism is interesting, but I'm not fully understanding the importance. We say it was done this way because a user would appreciate the speedup. The difference is one traversal versus expected one and one-half traversals. How slow was this traversal at the time for this difference to be significant?

It will depend on details like file system fragmentation (Windows XP could run on FAT32), but it could conceivably make a perceptible difference on a slow HDD when there are many pictures in the directory. You also have to check more error cases, for when the second iteration fails for some reason. The mindset was probably "why complicate the code with multiple iterations and make it less efficient?" when the efficient solution is straightforward and arguably simpler.

Apart from the performance issues, it also prevents a bug. If some files get deleted between the first and the second pass, then you end up with unexpected behaviour and probably a crash.

The current implementation has the same race condition: the sampled file may be deleted by the time SHSetUserPicturePath() is called.

Yes, but the the implementation with the additional iteration also has to have extra checks for that iteration, because it can't blindly iterate to the ith file, as there may not be i files anymore. So the implementation gets more complex overall.

Hard drives are measured in hundreds of IOPS at most. Then you have the 40 billion other things trying to eat those IOPS at startup.

Reply on news.ycombinator.com