upvote
I've measured NT Heap vs. Segment Heap for my RAM and CPU intensive workloads and got a steady 7% overall performance improvement. The combined workload finishes 7% quicker with the Segment Heap.

P.S. In Windows 95 - Windows Vista era, there was a good tradition of "Compatible with Windows XXX" certifications for apps. If MS did something like that for Windows 10/11 and included the segment heap tick mark into it, a considerably larger amount of apps and its users would benefit from increased performance. Think better energy consumption and eco-friendliness as additional bonuses.

P.S. 2: The problem with UWP was not the technology itself, it was the stubbornness to have it packaged and tied to The Store, all of which contradicts the very existence of Windows as an OS.

reply
UWP is not strictly tied to the Windows store (you can install UWP applications packaged in the right format(s) from the command line, for business deployments for instance), but it might as well be when it comes to consumers.

I can't really complain, though. If UWP would've broken through, the Steam Deck would've probably been a much more massive undertaking to get working right.

As long as developers can opt into the new system (which they can with the manifest approach), I don't think it matters whether you're doing UWP or traditional Windows applications.

Microsoft has added a mishmash of flags in the app manifest and transparently supports manifest-less applications, so developers don't have a need to ever bother including a manifest either.

It'd annoy a lot of people, but if Windows would show a "this app has been written for an older version of Windows and may be slower than modern applications" warning for old .exes (or maybe one of those popups they now like about which apps are slower than they could be), developers would have an incentive to add a manifest to their applications and Microsoft could enable a lot more of these optimisations for a lot more applications.

reply
For those interested, you can opt-in to this behavior via the application manifest for your own executables: set heapType to SegmentHeap https://learn.microsoft.com/en-us/windows/win32/sbscs/applic...
reply
This is the sort of extremely valuable hint that makes HN worthwhile.

Does that global registry key require a reboot, or does it just take effect on executable launch?

reply
This feels like it deserves to live somewhere on a blog, not as a comment on some forum. This is really interesting thanks for sharing.
reply
Agreed! Looks like it can be enabled with a manifest at build time too: https://learn.microsoft.com/en-us/windows/win32/sbscs/applic...
reply
> You can turn it on globally for all processes by creating a DWORD value named "Enabled" under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap, and giving it a value of 3

I had previously seen this described as 0 vs non-zero. Since you have some inside experience :), anything special about 3 instead? What about 2? How would I find these value meanings out on my own (if that's even possible)?

Thanks!

reply
It's a combinination of bit flags. The lowest bit controls whether segment heap is on or off. The 2nd lowest bit bit controls some additional optimizations that go along with it, something about multithreading. A value of 3 (both flags set) gives you identical behavior to what specifying <heapType>SegmentHeap</heapType> in your application manifest does.

Using the application manifest approach is the right way to ship software that opts into segment heap. The registry thing is just a convenience for local testing.

reply
How often does software actually ship with the opt in for segment heap turned on though ?

Anyway to globally turn it on when a blacklist or denylist or whatever in case something individual acts up ?

reply
Would the (not Framework) .NET apps I work on benefit from this?
reply
Any app using memory allocation functions would benefit from a newer heap implementation independently of a technology it's created with, unless it's actively constrained by compatibility burdens. In case of .NET, the memory layout compatibility is not something you usually care about unless the app loads old 3rd party .DLLs through P/Invoke. So for 99.9% of .NET (not Framework) apps, the segment heap should work just fine.
reply
Wonderful breakdown. I love reading this kind of thing. thank you
reply
Seems like a no brainer on virtualised environments for Windows servers ?

Also assuming that most Microsoft first party applications in Windows server (DNS, etc etc) would all be optimised for segment heap ?

reply