Live data from Hacker News

The Windows malloc() implementation from MSVCRT is slow

erikmcclure.com

181–187 of 187 posts

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

#181

Earlier quoted context omitted.

> The various shells running under the multiplexer overwrite each other's history. GitHub seems to have umpteen different variations on "store the shell history in a SQLite database": https://github.com/thenewwazoo/bash-history-sqlite https://github.com/trengrj/recent https://github.com/andmarios/bashistdb https://github.com/digitalist/bash_database_history https://github.com/quitesimpleorg/hs9001 https://github.com/…

My thought is to burn it all down. It's my very-background side project to do this; I have also seen a few startups trying it out. (My theory is that developers won't pay for tools, so I wouldn't start a company to do it. A few people use IntelliJ or whatever, that's about it. They're not going to buy a commercial ssh daemon and terminal emulator.) I will say that one should be wary of combining 3d graphics and font…

> My thought is to burn it all down

I have the exact same thought. I've been working on it, on-and-off, for years. I remember starting out when our son was a baby, and he's 9 now, and I still haven't got very far. Plus, now we've got two kids, and they are older, I have far less time to muck around with this stuff than I used to.

What I've realised after a while – "burn it all down" is unlikely to produce much results. I mean, if it is all just for fun (which is kind of all it is for me now), it doesn't really matter. But if one is hoping to make an impact in the real world, small incremental improvements building on pre-existing work are far more likely to do that than starting it all over from scratch, as tempting as that is.

> I will say that one should be wary of combining 3d graphics and font rendering and designing a programming language in the same project, at least if you want to get it done in less than 10 years. (I did talk myself out of writing a text editor, at least. Not touching that one.)

My priorities are somewhat different from yours. Own programming language? Yup, been through a few of those (every now and again I get fed up with it all and restart from scratch). 3D graphics? Well, I planned on having 2D graphics, never got very far with that, didn't even think of 3D. Mostly have just stuck to text mode, at one point I had my own incomplete clone of curses written in a mixture of my own programming language and Java (this was before I decided to abandon the JVM as a substrate and rewrite my own language in C–I started redoing my curses clone in C–why didn't I just use ncurses or whatever?–but it is very unfinished, never got anywhere near as far as my Java attempt did), also HTML to render in the browser.

But a text editor? Yeah, did that. Also, somewhat bizarrely, the text editor I wrote was a line editor (as in ed, ex, edlin, etc). Never actually used it that much for editing text. I meant to write a full-screen interface for it too (retracing the historical evolution from ex to vi), just have never got around to it.

> I don't have a good programming language spec

One thing I learned years ago – unless you love writing specs, they are a bit of a waste of time for this kind of stuff. Write your language first, create the spec later. Even for serious languages like Java, that's actually what happened (from what I understand)–the implementation of the language and the runtime was already several years old before they started writing the specs for them.

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

#182

Earlier quoted context omitted.

It sounds like they've invented 15 different ways to allocate memory rather than have malloc. What did they do that for? (Not to say malloc is a perfect API, it’s definitely oversimplified, but they probably didn’t solve any of its problems.)

malloc is just a C api, it’s not a syscall, and Linux is no different. malloc/free on Linux is probably using mmap under the hood, and doing some bookkeeping to decide when to decommit memory to give it back to the OS.

When did I say anything about syscalls or Linux?

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

#183
post #156

Earlier quoted context omitted.

Not kept up with the times? Registration free COM exists for several years now.

Wasn't there also a hacky way to achieve the same goal as registration-free COM even before it existed?

Probably, although I tend to stay away of such solutions, as they eventually turn into headaches to sort out in some machine, where the hack doesn't work as expected.

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

#184
post #173
post #161

Earlier quoted context omitted.

> Using a pure C interface escapes COM's requirement to register every component (regsvr32) [...] Another alternative if you want to stick with C++: make up your own lightweight COM Or you can combine both: use a pure C interface which returns COM objects. That way, you can keep using COM without having to register anything with regsvr32 or similar. > I have no idea if this trick will also work on Linux, I don't know…

Ah! Yeah, I've completely forgotten that the Itanium ABI also guarantees a standard vtable layout. Thanks! Were starting to convert my app from a Windows-only app to a cross platform one, so this makes me happy that my "COM lite" scheme would also be stable on linux. As for returning pure COM objects through a C interface: Yeah, I've considered that, but like I wrote in my comment below to pjmlp, I don't like COM per…

Due to experience trying to link some code, especially C++, I'd probably rather start by implementing a simplified COM system first rather than dealing with extern C

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

#185
post #156

Earlier quoted context omitted.

Not kept up with the times? Registration free COM exists for several years now.

Wasn't there also a hacky way to achieve the same goal as registration-free COM even before it existed?

For in-process DLL-based servers, you could try to implement CoCreateClass (IIRC) manually and bypass GUID-to-server lookup and go directly for loading a DLL and calling the method for getting the object from it.

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

#186
post #175

Earlier quoted context omitted.

You have it backwards, UWP is based on WinRT (which is built on top of the COM underpinnnings) and not the other way around.

Having used it since Windows 8 days, I know pretty much how it all goes. Nowadays there are two WinRT models, the original underlying UWP that grew out of the UAP / WinRT evolution introduced in Windows 8.1, to simplify what was originally split across phones, tablets and desktop. And now the WinRT implementation on top of Win32, started as Project Reunion, rebranded as WinAppSDK alongside WinUI 3.0.

I’m not trying to be particularly pedantic but that still doesn’t make WinAppSdk built on UWP; it’s mainly an expanded and cleaned-up collection of first-party cross-language wrappers/bridges/ffi to WinRT to hide the COM underpinnings plus unify some of the disparate Win32 vs WinRT APIs.

As you know, WinRT predates UWP. UWP as tech isn’t strictly defined but it includes things that are out of the scope of WinRT itself and aren’t available via WinAppSDK even now that UWP is finally, officially dead.

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

#187

Earlier quoted context omitted.

malloc is just a C api, it’s not a syscall, and Linux is no different. malloc/free on Linux is probably using mmap under the hood, and doing some bookkeeping to decide when to decommit memory to give it back to the OS.

When did I say anything about syscalls or Linux?

You said "they invented 15 ways instead of having malloc". By "they" you mean Microsoft right?

Windows does have malloc as a C api for programs using the C runtime library. Same as everywhere else.

Then, at the OS api level, there are indeed several memory management functions. But you usually don’t need them. Except if you are writing a custom memory allocator for instance. Also same as everywhere else.

So saying Windows has X memory management functions instead of malloc is incorrect.

Post reply on HN