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

51–60 of 187 posts

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

#51

Post by garaetjjte »

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…

>but Microsoft never considered the MSVCRT that ships with Windows to be public API

It was in the past. At first msvcrt.dll was the runtime library used up to Visual C++ 6. Later, VC++ moved to their own separate dlls, but you could still link with system msvcrt.dll using corresponding DDK/WDK up to Windows 7.

I'm also not sure that this is just ancient library left for compatibility, some system components still link to it, and msvcrt.dll itself seems to link with UCRT libraries.

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

#52

Post by sterlind »

pcl wrote: post #31
naniwaduni wrote: post #17

Earlier quoted context omitted.

Well, a pretty big part of the point of Linux is that it's not a Unix-descendant, just a Unix-clone.

What’s the distinction between those two?

Darwin forked BSD, and BSD is a fork of the original Unix source. Linux is a fresh implementation of POSIX, and doesn't directly inherit any code from Unix.

Linux is as much Unix as WSL1 was Linux - i.e. not at all, just clones.

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

#53

Post by londons_explore »

sterlind wrote: post #40
munch117 wrote: post #30

Earlier quoted context omitted.

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.

! 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...

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

#54

Post by dwheeler »

pcl wrote: post #31
naniwaduni wrote: post #17

Earlier quoted context omitted.

Well, a pretty big part of the point of Linux is that it's not a Unix-descendant, just a Unix-clone.

What’s the distinction between those two?

"Unix" implies paying annual fees for use of the "Unix" trademark, and/or at least direct descent from the original Unix code.

According to: https://kb.iu.edu/d/agat "To use the Unix trademark, an operating system vendor must pay a licensing fee and annual trademark royalties to The Open Group. Officially licensed Unix operating systems (and their vendors) include macOS (Apple), Solaris (Oracle), AIX (IBM), IRIX (SGI), and HP-UX (Hewlett-Packard). Operating systems that behave like Unix systems and provide similar utilities but do not conform to Unix specification or are not licensed by The Open Group are commonly known as Unix-like systems."

Many will include the *BSDs as a Unix, because their code does directly descend from the original Unix code. But Linux distros generally do not meet either definition of "Unix".

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

#55

Post by qsdf38100 »

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.

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

#56

Post by TonyTrapp »

garaetjjte wrote: post #51
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…

>but Microsoft never considered the MSVCRT that ships with Windows to be public API It was in the past. At first msvcrt.dll was the runtime library used up to Visual C++ 6. Later, VC++ moved to their own separate dlls, but you could still link with system msvcrt.dll using corresponding DDK/WDK up to Windows 7. I'm also not sure that this is just ancient library left for compatibility, some system components still lin…

> It was in the past. At first msvcrt.dll was the runtime library used up to Visual C++ 6.

At that time it was already a big mess, because at first it was the runtime library of Visual C++ 4 in fact! The gory details are here: https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=12...

> some system components still link to it

Some system components themselves are very much ancient and unmaintained and only exist for backwards compatibility as well.

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

#58

Post by CyberDildonics »

pjmlp wrote: post #36
jart wrote: post #27

Earlier quoted context omitted.

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

Since we are getting pedantic, Linux isn't a UNIX.

It's absurd you would call someone pedantic for saying malloc is in a library on linux after trying to say that malloc in a library on windows.

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

#59

Post by lkfjasdlkjfsad »

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…

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 communicating code blocks frustrating. i see new app features here and there, i saw some feature added the other day which won't help anyone. i just don't understand the prioritization of issues

i don't expect a direct answer to this, although i hope to read an explanation one day

EDIT: i removed content from this comment that was missing the point

Post reply on HN