Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's not exactly the same thing, but Windows used to have a thumb.db to store, well, thumbnails, in each folder that has thumbnail-able files.

I hated it, most of people hated it. MS finally got rid of it (in Vista or 7) and store thumbnails in a centralized place.

However, I now start to miss it.

I store lots of large image files (think 1200 dpi PNG scans) on my computer, and it took Windows years to create thumbnail for them, while locking the entire hard disk (and sometimes the whole explorer.exe) in the meantime. This process, while obviously is much slower on spinning HDD, it surprisingly isn't really that fast on NVME SSD, either.

This would be fine if it's a one-time process, but unfortunately the aforementioned centralized thumbnail cache either have an expiration time, or have a size limit (or both), so the reality is if I didn't visit a folder for awhile, its thumbnails are all gone, so they have to be generated again, make the explorer unresponsive for some time again.

I have been annoyed by this for long time but I don't have any solution. The best workaround is to only view such folders in list/detail mode, and rely on 3rd party image manager (I use XnView) to show the preview/thumbnail -- which has a much faster thumbnailing speed and more robust thumbnail cache management.



> This process, while obviously is much slower on spinning HDD, it surprisingly isn't really that fast on NVME SSD, either.

Windows is renowned for having awful performance in usecases involving accessing many small files even for read-only applications. I know a team that even went as far as testing switching away from Windows to build Windows apps and instead switched to cross-builds on Linux just to avoid that performance sinkhole. Meanwhile I worked on a multiplatform project where macOS builds on a Mac mini for the exact same project took less than half the time to build than on a beefed up Windows workstation.

Here's an interesting discussion on HN from a couple of years ago on this topic.

https://news.ycombinator.com/item?id=18783525


It doesn't help that corporate Windows machines are infested with AV snakeoil scanners slowing down FS access.


It took me forever to figure out that windows defender was what was slowing emacs down to a crawl on windows. I even went through the trouble of compiling native-comp and it was still slow.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: