3 ms·
There is no reason that processing a few million files could not be done at interactive speeds. Searching for certain filenames on Windows is awfully slow with
by danbruc 4y ago
There is no reason that processing a few million files could not be done at interactive speeds. Searching for certain filenames on Windows is awfully slow with Explorer, but there are tools like UltraSearch [1] which directly scans the Master File Table of NTFS volumes and will find all matching files orders of magnitudes faster.
Also the UI is not a problem, I experimented myself with something vaguely similar and it was relatively easy to have millions of nodes - I think I just used plain buttons controls for nodes - in WPF at interactive speed. I think it somehow involved quadtrees to make it fast, just naively instantiating millions of buttons did not work, but it was doable. This was however ages ago and my memories are quite fuzzy.
[1] https://www.jam-software.com/ultrasearch_free https://www.jam-software.com/ultrasearch_free
- d_tr 4y agoInteresting. Why doesn't the built-in search feature use a similar technique then?
- danbruc 4y agoBecause Explorer certainly relies on APIs that abstract away the file system details and the smallest common denominator is probably recursively walking the tree structure of the file system which is orders of magnitude slower than scanning through a few megabyte of a central database.
- anigbrowl 4y agoAlso it tries to search within files. I have a huge document library and it's often faster to look up a partial filename from the command line than to use Explorer's search, is slow and buries the file I want amid hundreds of irrelevant results.