Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Windows malloc() implementation from MSVCRT is slow

erikmcclure.com

Post reply on HN
Print view View original

111–120 of 187 posts

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

#111

Post by kazinator »

p_l wrote: post #100
kazinator wrote: post #72

Earlier quoted context omitted.

If you're writing in C++ on Windows, expose only COM (or at least COM-style) interface called through virtual functions on an object pointer. Then you can use whatever C++ run-time you want, internally. What you don't want is the other library calling C++ functions by name. Like you pass it some ostream object and it calls ostream::put or whatever, where that symbolically resolves to the wrong one.

It's also why all, or nearly all, new API on windows are done through COM. It also means that C++ or other runtimes don't pollute your ABI and make it annoyingly hard to access features from any random code.

Another reasonable choice for some components would be to have a purely C api; everything extern "C", and only PODs (plain old datastructures) in the arguments.

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

#112

Post by mananaysiempre »

password4321 wrote: post #110
p_l wrote: post #99

Earlier quoted context omitted.

Glibc is major source of "binary from X years ago doesn't work" in my experience, to the point that if I want to run stuff older than let's say 5 years I start by getting a docker container - or a specially taylored set of libs starting with dynamic linker itself. Somehow proprietary OpenGL drivers still worked, it was glibc related files that caused crashes. Thanks to symbol versioning I never know if a binary will…

For example: https://github.com/microsoft/vscode-remote-release/issues/10...

So a vscode thingie uploads a newer binary to an older host, tries to run it there, and fails? Because the people who built said binary did not care to make it backwards compatible (or better yet, statically linked)?

... Duh?

(I’m not an expert in VSCode DRM, to put it mildly, so I might be misinterpreting this discussion, but that’s what it looks like to me. Also, isn’t it referencing GLIBCXX i.e. libstdc++, which not even a part of Glibc?)

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

#113

Post by lkfjasdlkjfsad »

lkfjasdlkjfsad wrote: post #59
sterlind wrote: post #37

Earlier quoted context omitted.

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

any idea what the hell is going on with Teams? why can't i simply scroll up in my own conversations? let alone search them. the sticky sludge of communication in something as simple as chat has cost me hours since i was forced to use teams. outlook search is so superior to teams i'd easily prefer to have lync back. this one thing absolutely cripples communication. there are a list of other very basic issues that make…

downvote me all you want. maybe the quality of my comment was bad.

in my opinion, the team or leader who is responsible for prioritizing issues in Teams needs a major adjustment. their flaws are brazen and affecting all of us who are forced to use Teams for communication.

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

#114

Post by kccqzy »

assttoasstmgr wrote: post #107
wvenable wrote: post #102

Earlier quoted context omitted.

Apple wanted to force Cocoa on everyone but had to delay their OS an entire year to build Carbon so that developers would actually port their Mac apps to OS X.

A number of Apple's original core apps (like iTunes, AppleWorks, etc.) were Carbonized apps.

Finder was Carbon until 10.6. It's probably a message to show developers that Apple was serious about Carbon.

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

#115

Post by chunkyks »

Dylan16807 wrote: post #94
londons_explore wrote: post #48

Earlier quoted context omitted.

At one point MS was very keen for people to use MSI's rather than building custom installers that jam things into system32. Perhaps that was why.

But if you're using it for yourself you wouldn't want to put it in system32.

There was a looong period of time where a lot of developers felt entirely free to drop whatever they wanted into c:\Windows, System, System32, whatever. It's a big part of what led to windows getting a reputation for being poorly behaved/crashy/slow over time [leading to a lot of "have you tried reinstalling windows?" recommendations]

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

#116

Post by kazinator »

cesarb wrote: post #85
kazinator wrote: post #65

Earlier quoted context omitted.

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

> MSVCRT.DLL isn't the library "everyone" uses; just Microsoft programs, and some misguided freeware built with MinGW. There's a third set of users: programs built with old enough versions of the Microsoft compiler. Before Microsoft decided that every single version of its C compiler should use a different C runtime (and much later they changed their mind again), all Microsoft C and C++ compilers linked their output…

MinGW chose MSVCRT.DLL because it meets the definition of "System Library" referred to in the GNU Public License. There is a special exception that GPLed programs can be linked to a proprietary, closed-source component if it is a system library; i.e. something always installed and always present on a certain type of system to which that program is ported. Without that, you couldn't have GNU utilities as replacements for Unix utilities on a proprietary Unix, linking with its libc.

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

#117

Post by password4321 »

mananaysiempre wrote: post #112
password4321 wrote: post #110

Earlier quoted context omitted.

For example: https://github.com/microsoft/vscode-remote-release/issues/10...

So a vscode thingie uploads a newer binary to an older host, tries to run it there, and fails? Because the people who built said binary did not care to make it backwards compatible (or better yet, statically linked)? ... Duh? (I’m not an expert in VSCode DRM, to put it mildly, so I might be misinterpreting this discussion, but that’s what it looks like to me. Also, isn’t it referencing GLIBCXX i.e. libstdc++, which n…

> referencing GLIBCXX i.e. libstdc++, which not even a part of Glibc

You're right, so not an example of a glibc failure, but rather another standard library. Thanks!

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

#118

Post by barrkel »

qsdf38100 wrote: post #55
barrkel wrote: post #22

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.

Note that Windows has HeapAlloc and HeapFree, which provide all the functionality to trivially implement malloc and free. The C runtime is doing exactly that, except it adds a bit of bookkeeping on top of it IIRC. And in debug builds it adds support for tracking allocations.

VirtualAlloc is a better base for a custom memory allocator. It's closer to mmap + mprotect in functionality.

There's also CoTaskMemAlloc (aka IMalloc::Alloc). And COM automation has a bunch of methods which allocate memory for dynamically sized data, which could be abused for memory allocation - SafeArrayCreate, SysAllocString.

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

#119

Post by Shadonototra »

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.

what has LLVM to do with software development on windows?

because developing for windows is cancer that people fall back to LLVM and others

it's all on microsoft for not cleaning their mess

even apple offers a better story than the platform for "developers, developers, developers, developers"

a shame, a well deserved shame, a hall of shame

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

#120

Post by Tringi »

mananaysiempre wrote: post #93
bjourne wrote: post #20

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…

Isn’t every (release-mode) Microsoft CRT malloc a thin wrapper around KERNEL32!HeapAlloc (thus eventually NTDLL!RtlAllocateHeap)? CRTDLL did it, MSVCRT did it, UCRTBASE still seems to be doing it.

Yes, it is.
Post reply on HN