Hacker News Reader

Comment by madibo3156 | Hacker News Reader

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?

View on HN

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