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.
The Windows malloc() implementation from MSVCRT is slow
21–30 of 187 posts
Re: The Windows malloc() implementation from MSVCRT is slow
#22Windows 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.
Re: The Windows malloc() implementation from MSVCRT is slow
#23There is no Windows malloc(). Only UNIXes have the C API as part of the OS API.
Re: The Windows malloc() implementation from MSVCRT is slow
#24"Don't use spinlocks in user-land."
Re: The Windows malloc() implementation from MSVCRT is slow
#25If 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 anyw…
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 C++ codebases, even on Linux and Darwin. Degradation on Linux + macOS is still there, but more insidious because the default is so good that simple apps don't see it.
Re: The Windows malloc() implementation from MSVCRT is slow
#26Has 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)”.
I just call Linx+Mac+Bsds Unix (not “Unix-like” and certainly not that “*nix” nonsense). I don’t respect Unix enough to be perfectly precise with it.
Re: The Windows malloc() implementation from MSVCRT is slow
#27There is no Windows malloc(). Only UNIXes have the C API as part of the OS API.
malloc() isn't part of the Linux API which provides mmap().
Re: The Windows malloc() implementation from MSVCRT is slow
#28Well... 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…
I suspect they are actually talking about the modern/redistributable C/C++ runtime, not the old msvcrt.dll.
Microsoft refer to the modern libraries as the "Microsoft C and C++ (MSVC) runtime libraries", so shortening that to MSVCRT doesn't seem unreasonable.
Re: The Windows malloc() implementation from MSVCRT is slow
#29Well... 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…
there's a weird licensing thing for the VC runtime where you can't redistribute the dll alongside your code unless you have a special license. instead, you have to install it as an MSI. I have no idea why they created that restriction. I even work for MS and it baffles me.
Re: The Windows malloc() implementation from MSVCRT is slow
#30I 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…
You shouldn't read too much into the PowerShell story. Creating your own programming language is in most cases a frivolous vanity project. Spending company resources on your own frivolous vanity projects is the sort of thing that can get you fired.