The Windows malloc() implementation from MSVCRT is slow

Not that it helps here, but Microsoft never considered the MSVCRT that ships with Windows to be public API. This is not the &quot;Windows allocator&quot;, this is the (very) old MSVC runtime library&#x27;s allocator. Of course that doesn&#x27;t keep anyone from using this library because it&#x27;s present on any Windows system, unlike the newer MSVC versions&#x27; runtime library. Using the allocator from a later MSVC&#x27;s runtime library would provide much better results, as would writing a custom allocator on top of Windows&#x27; heap implementation.<p>MSVCRT basically just exists for backwards compatibility. It&#x27;s impossible to improve this library at this point.

Well... Who told you to link to MSVCRT (the one in System32)? Not Microsoft that&#x27;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&#x27;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.<p>&quot;Windows is not a Microsoft Visual C&#x2F;C++ Run-Time delivery channel&quot; <a href="https:&#x2F;&#x2F;devblogs.microsoft.com&#x2F;oldnewthing&#x2F;20140411-00&#x2F;" rel="nofollow">https:&#x2F;&#x2F;devblogs.microsoft.com&#x2F;oldnewthing&#x2F;20140411-00&#x2F;</a>

I wonder how much of this is the development culture at MS. <a href="https:&#x2F;&#x2F;www.theregister.com&#x2F;2022&#x2F;05&#x2F;10&#x2F;jeffrey_snover_said_microsoft_demoted&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.theregister.com&#x2F;2022&#x2F;05&#x2F;10&#x2F;jeffrey_snover_said_m...</a> (“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.”)<p>In that environment I can imagine nobody wants to be on the hook for messing with something fundamental like malloc().<p>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.

Windows doesn&#x27;t have a malloc. The API isn&#x27;t libc like conventional Unix and shared libraries on Windows don&#x27;t generally expect to be able to mutually allocate one another&#x27;s memory. Msvcrt as shipped is effectively a compatibility library and a dependency for people who want to ship a small exe.

The other inaccuracies in this article have already been covered. I noticed there was also a weird rant about mimalloc in there (&quot;For some insane reason, mimalloc is not shipped in Visual Studio&quot;).<p>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&#x27;s pretty nice, but I also wouldn&#x27;t expect it to be somehow pushed as the default choice for Windows allocators.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;mimalloc&#x2F;graphs&#x2F;contributors" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;mimalloc&#x2F;graphs&#x2F;contributors</a>

Seeing someone refer to any piece of software technology as a &quot;trash fire&quot; makes it harder for me to view them as credible. It&#x27;s unnecessarily divisive and insulting, and it means it&#x27;s unlikely they will have any appreciation of the tradeoffs present during initial design and implementation.

The Factorio team were looking at a performance bug recently &amp; tracked it down to similar: <a href="https:&#x2F;&#x2F;forums.factorio.com&#x2F;viewtopic.php?f=7&amp;t=102388" rel="nofollow">https:&#x2F;&#x2F;forums.factorio.com&#x2F;viewtopic.php?f=7&amp;t=102388</a><p><a href="https:&#x2F;&#x2F;developercommunity.visualstudio.com&#x2F;t&#x2F;mallocfree-dramatic-performance-slowdown&#x2F;552439" rel="nofollow">https:&#x2F;&#x2F;developercommunity.visualstudio.com&#x2F;t&#x2F;mallocfree-dra...</a>

I&#x27;m curious whether the &quot;new&quot;(ish) segment heap would address some of the author&#x27;s issues.<p>It&#x27;s poorly documented, so I can&#x27;t find a reference explaining what it is on MSDN save for a snippet on the page about the app manifests[1]. There&#x27;s some better third-party &quot;documentation&quot;[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.<p>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.<p>[1] <a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;windows&#x2F;win32&#x2F;sbscs&#x2F;application-manifests#heaptype" rel="nofollow">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;windows&#x2F;win32&#x2F;sbscs&#x2F;applica...</a><p>[2] (PDF warning) <a href="https:&#x2F;&#x2F;www.blackhat.com&#x2F;docs&#x2F;us-16&#x2F;materials&#x2F;us-16-Yason-Windows-10-Segment-Heap-Internals.pdf" rel="nofollow">https:&#x2F;&#x2F;www.blackhat.com&#x2F;docs&#x2F;us-16&#x2F;materials&#x2F;us-16-Yason-Wi...</a><p>[3] <a href="https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=1102281" rel="nofollow">https:&#x2F;&#x2F;bugs.chromium.org&#x2F;p&#x2F;chromium&#x2F;issues&#x2F;detail?id=110228...</a>

This rant was rather devoid of relevant technical detail.<p>I mean, why exactly is the malloc of the compatibility msvcrt so slow compared to newer allocators? What is it doing?<p>An analysis of that would have been some actual content of interest.

So why is it a trash fire? It&#x27;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.

My knowledge is like 10 years old - For a long time, Microsoft&#x27;s stl implementation was based on their licensning of dinkumware&#x27;s STL (<a href="https:&#x2F;&#x2F;www.dinkumware.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.dinkumware.com&#x2F;</a>). Not something maintained in house. It seemed to work OK&#x27;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.

Just wait until you try to use it from multiple threads at the same time!

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.

&gt; it basically represents control flow as a gigantic DAG<p>Control flow is not a DAG.

&gt; 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.<p>Where do people get their opinions from? It seems like opinions now spread like memes - someone you respect&#x2F;has done something in the world says it, you repeat it without verifying any of their points. It seems like gamedev has the highest &quot;C++ bad and we should all program in C&quot; commmunity out there.<p>If you want a good malloc impl just use tcmalloc or jemalloc and be done with it

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)”.

There is no Windows malloc(). Only UNIXes have the C API as part of the OS API.

&quot;Don&#x27;t use spinlocks in user-land.&quot;

If you&#x27;re depending on the performance of malloc, you&#x27;re either using the language incorrectly or using the wrong language. There is no such thing as a general purpose <i>anything</i> when you care about performance, there&#x27;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 <i>anyway</i>.