The Windows malloc() implementation from MSVCRT is slow
erikmcclure.com
The Windows malloc() implementation from MSVCRT is slow
1–10 of 187 posts
Re: The Windows malloc() implementation from MSVCRT is slow
#2I wonder how much of this is the development culture at MS. https://www.theregister.com/2022/05/10/jeffrey_snover_said_m... (“When I was doing the prototype for what became PowerShell, a friend cautioned me saying that was the sort of thing that got people fired.”)
In that environment I can imagine nobody wants to be on the hook for messing with something fundamental like malloc().
The complete trash fire that is O365 and Teams—for some reason the new Outlook kicks you out to a web app just to manage your todos—suggests to me that Microsoft may be suffering from a development culture that’s more focused on people protecting fiefdoms than delivering the best product. I saw this with Nortel before it went under. It was so sclerotic that they would outsource software development for their own products to third party development shops because there was too much internal politics to execute them in house.
Re: The Windows malloc() implementation from MSVCRT is slow
#3I'm curious whether the "new"(ish) segment heap would address some of the author's issues.
It's poorly documented, so I can't find a reference explaining what it is on MSDN save for a snippet on the page about the app manifests[1]. There's some better third-party "documentation"[2] that gets into some specifics of how it works, but even that is light on the real-world operational details that would be helpful here.
Chrome tried it out and found[3] it to be less than suitable due to its increased CPU cost, which might presage what Erik would see if they enabled it.
[1] https://docs.microsoft.com/en-us/windows/win32/sbscs/applica...
[2] (PDF warning) https://www.blackhat.com/docs/us-16/materials/us-16-Yason-Wi...
[3] https://bugs.chromium.org/p/chromium/issues/detail?id=110228...
Re: The Windows malloc() implementation from MSVCRT is slow
#4So why is it a trash fire? It's just slow? Or is there something else wrong with it? I thought the author was going to say it did something insane or was buggy somehow.
Re: The Windows malloc() implementation from MSVCRT is slow
#5Has everyone forgotten that Unix is the common ancestor of Linux and every other Unixlike? I’m seeing an uptick of people writing nonsensical comments like “this was written for Linux (or Mac OS X, which implements POSIX and is therefore really Linux in drag)”.
Re: The Windows malloc() implementation from MSVCRT is slow
#6Just wait until you try to use it from multiple threads at the same time!
Re: The Windows malloc() implementation from MSVCRT is slow
#7Not that it helps here, but Microsoft never considered the MSVCRT that ships with Windows to be public API. This is not the "Windows allocator", this is the (very) old MSVC runtime library's allocator. Of course that doesn't keep anyone from using this library because it's present on any Windows system, unlike the newer MSVC versions' runtime library. Using the allocator from a later MSVC's runtime library would provide much better results, as would writing a custom allocator on top of Windows' heap implementation.
MSVCRT basically just exists for backwards compatibility. It's impossible to improve this library at this point.
Re: The Windows malloc() implementation from MSVCRT is slow
#8> I was taught that to allocate memory was to summon death itself to ruin your performance. A single call to malloc() during any frame is likely to render your game unplayable. Any sort of allocations that needed to happen with any regularity required writing a custom, purpose-built allocator, usually either a fixed-size block allocator using a freelist, or a greedy allocator freed after the level ended.
Where do people get their opinions from? It seems like opinions now spread like memes - someone you respect/has done something in the world says it, you repeat it without verifying any of their points. It seems like gamedev has the highest "C++ bad and we should all program in C" commmunity out there.
If you want a good malloc impl just use tcmalloc or jemalloc and be done with it
Re: The Windows malloc() implementation from MSVCRT is slow
#9Has everyone forgotten that Unix is the common ancestor of Linux and every other Unixlike? I’m seeing an uptick of people writing nonsensical comments like “this was written for Linux (or Mac OS X, which implements POSIX and is therefore really Linux in drag)”.
Apparently yes, because all I ever hear is "macOS is like Linux" and even "macOS is really Linux behind the scenes" from less enlightened people.
Re: The Windows malloc() implementation from MSVCRT is slow
#10> I was taught that to allocate memory was to summon death itself to ruin your performance. A single call to malloc() during any frame is likely to render your game unplayable. Any sort of allocations that needed to happen with any regularity required writing a custom, purpose-built allocator, usually either a fixed-size block allocator using a freelist, or a greedy allocator freed after the level ended. Where do peo…
As always there is some truth to it - the problem of the MSVCRT malloc described in this blog article is the living proof of that - but these days it's definitely not a rule that will be true in 100% of cases. Modern allocators are really fast.