The Windows malloc() implementation from MSVCRT is slow • Hacker News Board

Re: The Windows malloc() implementation from MSVCRT is slow

#61

Post by rayiner » Sat, Jul 02, 2022, 10:01 PM UTC

sterlind wrote: post #37

rayiner wrote: post #2

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 O36…

(I work for MS, though in core Azure rather than Office or Windows.) I think that PowerShell story was how old MS worked, back in the days of stack ranking, hatred of Linux and the Longhorn fiasco. things inside the company are a lot more functional now. I saw internal politics drama at my first position, but once I moved everything was chill, and experimentation and contributing across team boundaries was actively e…

It was interesting the see them switch back to Win32 after all of these greenfield alternatives that quickly died. (WPF, WinRT, etc.) Makes you wonder what was going on during that time. Contrast Apple which has been with Cocoa which is an evolution of Next Step.

Re: The Windows malloc() implementation from MSVCRT is slow

#62

Post by tick_tock_tick » Sat, Jul 02, 2022, 10:09 PM UTC

moonchild wrote: post #18

> it basically represents control flow as a gigantic DAG Control flow is not a DAG.

For it to be a DAG you'd have the solve the halting program wouldn't you?

Re: The Windows malloc() implementation from MSVCRT is slow

#63

Post by hughw » Sat, Jul 02, 2022, 10:09 PM UTC

londons_explore wrote: post #53

sterlind wrote: post #40

Earlier quoted context omitted.

! I disagree. CMD badly needed replacing. MS needed a new shell language. A functional company would connect people with a passion for X with the resources to achieve X, if X has a chance of helping the company. Windows Terminal and WSL show how far MS has come from the PS days. (Disclaimer: I work for MS)

I think the smart move would have been to make an official port of bash...

Maybe that's how we got WSL

Re: The Windows malloc() implementation from MSVCRT is slow

#64

Post by dzaima » Sat, Jul 02, 2022, 10:10 PM UTC

oddity wrote: post #25

mwcampbell wrote: post #15

Earlier quoted context omitted.

The whole point of the article, though, was that the system malloc was good enough on Linux and Darwin.

This misses the point of my comment. When you put faith in malloc, you're putting hope in a lot of heuristics that may or may not degenerate for your particular workload. Windows is an outlier with how bad it is, but that should largely be irrelevant because the code should have already been insulated from the system allocator anyway. An over-dependence on malloc is one of the first places I look when optimizing old…

Except that I'd guess that there is no "good" case in the case for MSVCRT's malloc. You shouldn't assume malloc is free, but you should also be able to assume it won't be horrifyingly slow. Just as much as you should be able to rely on "x*y" not compiling to an addition loop over 0..y (which might indeed be very fast when y is 0).

Yes, this unfortunately isn't the reality MSVCRT is in, but it is quite a reasonable expectation.

Re: The Windows malloc() implementation from MSVCRT is slow

#65

Post by kazinator » Sat, Jul 02, 2022, 10:18 PM UTC

jart wrote: post #33

TonyTrapp wrote: post #7

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 prov…

It's effectively mandatory. Microsoft provides about twelve different C Runtimes. But if you're building something like an open source library, you can't link two different C runtimes where you might accidentally malloc() memory with one and then free() with the other. If you want to be able to pass pointers around your dynamic link libraries, you have to link the one C runtime everyone else uses, which is MSVCRT. Al…

C applications targeting Windows must provide their own C library with malloc and free (if they are using the "hosted implementation" features of C).

MSVCRT.DLL isn't the library "everyone" uses; just Microsoft programs, and some misguided freeware built with MinGW.

Even if ADVAPI32.DLL uses MSVCRT.DLL, it's not going to mistakenly call the malloc that you provide in your application; Windows DLL's don't even have that sort of global symbol resolution power.

I would be very surprised if any public API in ADVAPI32 returns a pointer that the application is required to directly free, or accept a pointer that the application must malloc. If that were the case, you'd have to attach to MSVCRT.DLL with LoadLibrary, look up those functions with GetProcAddress and call them that way.

Windows has non-malloc allocators for sharing memory that way among DLL's: the "Heap API" in KERNEL32. One component can HeapAlloc something which another can HeapFree: they have to agree on the same heap handle, though. You can use GetProcessHeap to get the default heap for the process.

It may be that the MSVCRT.DLL malloc uses this; or else it's based on VirtualAlloc directly.

Re: The Windows malloc() implementation from MSVCRT is slow

#66

Post by Sesse__ » Sat, Jul 02, 2022, 10:18 PM UTC

TonyTrapp wrote: post #7

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 prov…

Win32 has an allocator (HeapAlloc), and it is similarly slow and low-concurrent. Even if you enable the newer stuff like LFH.

Re: The Windows malloc() implementation from MSVCRT is slow

#67

Post by MarkSweep » Sat, Jul 02, 2022, 10:21 PM UTC

DHowett wrote: post #3

I'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. C…

The one other piece of “documentation” that I know of is this blog post:

https://blogs.windows.com/windowsexperience/2020/05/27/whats...

It mentions that the segment heap is used by default for UWP apps and reduces memory usage of Edge.

Re: The Windows malloc() implementation from MSVCRT is slow

#68

Post by leajkinUnk » Sat, Jul 02, 2022, 10:27 PM UTC

FreakLegion wrote: post #35

TonyTrapp wrote: post #7

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 prov…

There's also UCRT, which ships with the OS since Windows 10. The logic of this rant was a real head-scratcher. If you must blame one side, it's LLVM. Fragmentation of C runtimes is annoying but inescapable. Glibc for example isn't any better.

Could you elaborate why Glibc isn't any better?

I remember some funny problems with Glibc, like, 20 years ago, but it's been invisible to me (as a user) since then. You get a new Glibc, old binaries still work, it's fine.

Re: The Windows malloc() implementation from MSVCRT is slow

#69

Post by Someone » Sat, Jul 02, 2022, 10:28 PM UTC

chrisseaton wrote: post #4

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.

Also, is it slow because it’s badly implemented, or is it better than other mallocs in some other respect? Maybe, dating from decades ago, it’s better in the memory usage front?

Re: The Windows malloc() implementation from MSVCRT is slow

#70

Post by leajkinUnk » Sat, Jul 02, 2022, 10:30 PM UTC

plorkyeran wrote: post #39

jart wrote: post #27

Earlier quoted context omitted.

malloc() isn't part of the Linux API which provides mmap().

Libc being just a library is indeed one of the ways that Linux is unlike Unix.

What do you mean by "Unix"? Are you talking about some specific Unix version, or is there something in the POSIX spec that says that libc isn't a library?