by TonyTrapp on 7/2/22, 8:51 PM
Not 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.
by bjourne on 7/2/22, 9:07 PM
Well... Who told you to link to MSVCRT (the one in System32)? Not Microsoft that's for sure. New software is supposed to link to the Visual Studio C runtime it was compiled with and then ship that library alongside the application itself. Even if you don't compile with VS you can distribute the runtime library (freely downloadable from some page on microsoft.com). Ostensibly, that library contains an efficient malloc. If you willingly link to the MSVCRT Microsoft for over a decade has stated is deprecated and should be avoided you are shooting yourself in the foot.
"Windows is not a Microsoft Visual C/C++ Run-Time delivery channel" https://devblogs.microsoft.com/oldnewthing/20140411-00/
by rayiner on 7/2/22, 8:45 PM
I 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.
by barrkel on 7/2/22, 9:09 PM
Windows doesn't have a malloc. The API isn't libc like conventional Unix and shared libraries on Windows don't generally expect to be able to mutually allocate one another's memory. Msvcrt as shipped is effectively a compatibility library and a dependency for people who want to ship a small exe.
by evmar on 7/2/22, 10:45 PM
The other inaccuracies in this article have already been covered. I noticed there was also a weird rant about mimalloc in there ("For some insane reason, mimalloc is not shipped in Visual Studio").
My understanding is mimalloc is basically a one-person project[1] from an MSR researcher in support of his research programming languages. It sounds like it's pretty nice, but I also wouldn't expect it to be somehow pushed as the default choice for Windows allocators.
[1]: https://github.com/microsoft/mimalloc/graphs/contributors
by bcbrown on 7/2/22, 9:07 PM
Seeing someone refer to any piece of software technology as a "trash fire" makes it harder for me to view them as credible. It's unnecessarily divisive and insulting, and it means it's unlikely they will have any appreciation of the tradeoffs present during initial design and implementation.
by trollied on 7/3/22, 6:44 AM
by DHowett on 7/2/22, 8:48 PM
by denkshom on 7/2/22, 10:55 PM
This rant was rather devoid of relevant technical detail.
I mean, why exactly is the malloc of the compatibility msvcrt so slow compared to newer allocators? What is it doing?
An analysis of that would have been some actual content of interest.
by chrisseaton on 7/2/22, 8:49 PM
So 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.
by softwaredoug on 7/2/22, 8:56 PM
My knowledge is like 10 years old - For a long time, Microsoft's stl implementation was based on their licensning of dinkumware's STL (
https://www.dinkumware.com/). Not something maintained in house. It seemed to work OK'ish - giving lowest common denominator functionality. However, it was pretty easy to create higher performing specialized data structures for your use case then what seemed like simple uses of dinkumware STL.
by Sesse__ on 7/2/22, 8:49 PM
Just wait until you try to use it from multiple threads at the same time!
by shaggie76 on 7/2/22, 11:11 PM
I wonder if he was running with the debugger attached; we also saw atrocious performance with MSVCRT malloc until we set _NO_DEBUG_HEAP=1 in our environment.
by moonchild on 7/2/22, 9:04 PM
> it basically represents control flow as a gigantic DAG
Control flow is not a DAG.
by somerando7 on 7/2/22, 8:54 PM
> 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
by KerrAvon on 7/2/22, 8:49 PM
Has 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)”.
by pjmlp on 7/2/22, 9:09 PM
There is no Windows malloc(). Only UNIXes have the C API as part of the OS API.
by fguerraz on 7/2/22, 9:11 PM
"Don't use spinlocks in user-land."
by oddity on 7/2/22, 9:00 PM
If you're depending on the performance of malloc, you're either using the language incorrectly or using the wrong language. There is no such thing as a general purpose anything when you care about performance, there's only good enough. If you are 1) determined to stick with malloc and 2) want something predictable and better, then you are necessarily on the market for one of the alternatives to the system malloc anyway.