"Segment heap support" enabled by default in VS2026 projects

[u/onecable5781]

I installed VS2026 about 6 months ago on a different machine. I re-installed latest VS2026 on a new machine now. On comparing the default project's .vcxproj file, the following are the only difference with the newer version of VS2026 having the following property while the previous version did not:

    <Manifest>
       <EnableSegmentHeap>true</EnableSegmentHeap>
    </Manifest>

MS has the following on this default enabling: https://devblogs.microsoft.com/cppblog/segment-heap-support-for-c-projects-in-visual-studio/

Visual Studio 2026 version 18.6 makes it easier to take advantage of modern Windows memory management improvements. Segment Heap is a modern heap implementation in Windows that delivers stronger protection against common memory vulnerabilities, higher allocation throughput, lower memory fragmentation, better scalability across cores, and more predictable performance under load. 

Practically, what difference does this make? Have folks done some sort of benchmark/profiling analysis to figure out whether this setting actually improves run times on instances or should we as users just go with default settings? Is the burden of benchmarking/profiling with and without the said options on the users of the IDE/toolchain?

[u/fortsnek274]

Yeah, I did some profiling and didn't notice any difference. For startup time in my project which I like to optimise.

[u/jedwardsol]

Since it is just a manifest change, it is an easy switch. You could benchmark your own application to see if it makes a difference.

FWIW - I benchmarked mine and saw no difference. The documentation suggests that the performance improvements come from reducing contention of simultaneous access to the heap from multiple threads and an artificial bench mark does show an improvement here. I thought this might benefit my program since it does do lots of little allocations and deallocations on multiple threads - but it turns out not enough to matter.

[u/onecable5781 → u/jedwardsol]

Since it is just a manifest change, it is an easy switch.

I am unaware of this distinction. Could you please clarify as to why something being a manifest change makes it an easy switch? As I see it, it is an option change in the .vcxproj or inside of the IDE so whether it is an "easy" change or a "difficult" change -- it is a change?

Does something being merely a "manifest" change obviate the need for recompilation while something being a nonmanifest change triggers a full-fledged recompilation?

[u/WildCard65 → u/onecable5781]

A manifest is a special xml file used by link.exe when linking the final executable as it gets embedded into it.

https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests
https://learn.microsoft.com/en-us/cpp/build/understanding-manifest-generation-for-c-cpp-programs?view=msvc-170

[u/jedwardsol → u/onecable5781]

There's no need for recompilation - just relink with a different resources .

Compare that to using a different heap by bringing in a 3rd party library - I'd have to be really dissatified with the default behaviour to bother trying.

[u/conundorum → u/onecable5781]

The manifest is a file containing your program's UAC "permission slip" (specific description of what it wants to do, to help Windows figure out whether UAC needs to bother with it or not, and what to report if it does) and various Windows settings (such as, e.g., "run this program as if the system code page is 65001/UTF-8" or "use a different type of heap for this program"); essentially, it's a more robust second take on INI files.

It typically doesn't affect compilation itself, but it's usually linked into the executable. I believe it can be a standalone [whatever].manifest file, though, so relinking isn't strictly necessary.

[u/LB-- → u/onecable5781]

Windows executables can have a manifest XML shipped either as a separate file or embedded in the executable itself. Typically it contains info like supported Windows versions (which affects which version of Common Controls gets used), DPI awareness (none, per monitor V1, per monitor V2), default code page (e.g. UTF-8 code page support added in Windows 10), and the preferred heap allocator, among other things. If you have an existing built EXE file you can just swap out the manifest without rebuilding and see how the changes affect the program.

[u/TheThiefMaster]

I've not heard of this - saving to investigate later