On Fri, 11/6/2026 1:59 AM, Lumberdog wrote:
On 11/5/26 17:11, Hank Rogers wrote:
Maria Sophia wrote on 11/5/2026 12:35 AM:
ÿ "Everything" is a search engine that locates files and folders
ÿÿ by filename instantly for Windows.
I have 1,722,821 "objects" on Windows 10. Is that a lot?
It's faster than superman.
What's your experience with it?
You tell us Arlen.ÿ Did it add value for you?
Maybe you could compose a full tutorial on it?
And I think he should share that list of 1,722,821 "objects" with us.
They're all Python scripts.
Just for a quick comparison...
C: 391,327 (has a few VMs)
H: 461,961 (has Visual Studio Community edition)
S: 10,316 bigger files
P: 191 bigger still files
I'm going to have to start writing some Python scripts
to catch up. That's not nearly enough files.
*******
I have a couple implementation demos of findnextfile. This one
can list a million files per second (on my RAMDrive).
https://learn.microsoft.com/en-us/windows/win32/fileio/listing-the-files-in-a-directory
Whereas this one displays an absolute path, and runs at 1/3rd the rate.
Just the execution of that number of printf statements, erodes the speed. That's why, if you want to win some races, you have to reduce the usage
of printf.
https://rosettacode.org/wiki/Walk_a_directory/Recursively#C
I don't think the code I've written, to parse the $MFT goes nearly
that fast. Neither does the nfi.exe that Microsoft made, read the $MFT that fast.
# If you need some source code to inform your NTFS $MFT parser.
# Not a complete implementation, so you still have work to do.
https://handmade.network/forums/articles/t/7002-tutorial_parsing_the_mft
the findnextfile code is one kick-ass piece of code in the Microsoft library. It seems to be (functionally) reading the $MFT at 4GB/sec (and it only selectively
examines what it is hoovering in). I can know that, because I have
a $MFT here that is over 60GB in size, for test :-) That's a pathological
case, which is both good and bad. For example, using File Explorer (oink!)
to count the files in the test object, that takes *two hours*
on the RAMDrive. How you interface to your storage on the machine,
there is quite a spread on performance.
If I need real performance, I use TMPFS on Linux. Which is not good
for long term usage (I would expect fragmentation slows it down as
time passes), but if you want to do drag race runs, it's pretty good
for those. When you run a Linux LiveUSB, half the RAM on the machine
is set aside for a RAMdrive. The /tmp running that way, is hosted
on RAM, and then you can do your benchmark run there.
*******
What slows down Everything.exe, is... progress.
When the first release came out, I suspect it was just processing
the $MFT and not gathering any details like "dates" for files.
The $MFT phase might only take it a few seconds (much less than
my parser).
But when it wants to add dates to the database or file it is generating,
that takes a stat() type process per file, and those are more expensive.
It might take 15-20 seconds to backfill by doing that. So when the
developer at Voidtools added the additional fields, that spoiled the
really speedy first implementation.
This is how you get Everything to make you a text file.
everything.exe -create-filelist every_c.txt "C:"
And that will seem to come back almost right away when
your run it. Part of the run is in the background.
You have to "monitor" the every_c.txt file and watch
it until it stops growing, to determine the process is
complete.
Paul
--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)