I think it was more the extra layers of indirection added to function environment\effectively global variable access added in 5.2 .
The removal of scanning for changed userdata finalizer meta method in 5.2 is just a commonsense fix for bad design that made GC atomic phase run time, thats not incremental scale up with the number of GC userdata objects alive no matter if they have a finalizer or not.
5.1 had function environments, then 5.2 changed them from a hidden value to a hardcoded variable name that was easier to change. How did that add extra indirection or slow anything down?
There is work being done on Git to add pluggable object backends[1] by some GitLab devs that could changes things up a bit and make large object handling not suck Maybe Lore could act like a promisor remote to pull large objects from as well for interop.
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.
`rmdir /s /q` in a command prompt is significantly faster than Windows Explorer.
Yes C: is slow due to filters and Dev Drive is faster; but this difference can only be felt when using the command line; Windows Explorer has so much additional overhead that the overhead from file filters is insignificant in comparison.
Sure, my point wasn't that Windows Explorer is faster or slower compared to the command line or other OSes, but that deletion can be faster or slower (for Windows Explorer) depending on other factors too, like as per my example where it speeds up by 200% when I turn off that TortoiseGit option, which is nothing to scoff at.
Your dismissive tone implies you think I’m lying or something about my stated (and reproduceable) experience that deletions absolutely run a 1/3rd slower with certain software installed.
You gave an example of a third party program (TortoiseGit) slowing down deletion and implied Defender would also make it slower.
Im saying I have Win10 with everything ripped out, no defender, no logging, no tracelogging, no telemetry, zero filesystem filters/hooks. Delete speed is in the same ballpark as on freshly installed system.
I think they just swapped out LuaJIT's modified built-it dlmalloc[1] with some standard allocator. Then just set some turning values of the allocator to make to more eager to return pages with no allocations left to the OS.
LuaJIT has always had pluggable allocator system you can set at state construction time[2], it did have a restriction you could only use the built-it allocator for 64 bit builds if you don't use the GC64 build option, but thats been default enabled for a while now.
reply