Part of Windows Explorer actually does tons of tiny 4 byte ReadFile calls in to its tracking database like file when you delete a file. If you deleting lots of files this quickly adds up.
Part of Windows Explorer actually does tons of tiny 4 byte ReadFile calls in to its tracking database like file when you delete a file. If you deleting lots of files this quickly adds up.
Is this why Windows takes so long to delete things?? Presumably those reads aren't done when using del from a console as that always seems a bit faster.
Its slowness is also a function of security software or any other file system "filters" (I believe they're called) are installed.
For example, I run TortoiseGit which has a caching feature which is supposed to make it faster at showing what to commit. Disabling it increases the number of items I can delete per second in my Windows Explorer from about 1000 to about 3000 while making not making TortoiseGit operations meaningfully slower (that I can tell).
This is a Dev Drive [0] on my machine, it would probably be slower on my C: drive which has full Windows Defender real time file scanning.
[0]: https://learn.microsoft.com/windows/dev-drive/
Windows Explorers zip implementation also seams to do 1 byte reads by the speed is has compared to every other zip implementation.
It is frustrating how slow .zip (and more recently .7z) support built into Windows Explorer is.
This is a great article on why it's so unreasonably slow to modify these archives: https://textslashplain.com/2021/06/02/leaky-abstractions/
But it doesn't seem to explain why it's so much slower at regular extraction.