3 ms·

It displays ALL of the nodes, given the millions of files and thousands of folders on a typical computer these days, some form of pruning would be required. Ju

It displays ALL of the nodes, given the millions of files and thousands of folders on a typical computer these days, some form of pruning would be required. Just loading all the nodes would take a few minutes on most computers.

ykonstant 4y ago
>some form of pruning would be required. ...sure. There you go.
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 ago
  Interesting. Why doesn't the built-in search feature use a similar technique then?
  - danbruc 4y ago
    Because 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 ago
      Also 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.

ykonstant 4y ago

>some form of pruning would be required. ...sure. There you go.

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 ago
Interesting. Why doesn't the built-in search feature use a similar technique then?
- danbruc 4y ago
  Because 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 ago
    Also 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.