ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
77% Positive
Analyzed from 1737 words in the discussion.
Trending Topics
#windows#server#microsoft#heap#linux#segment#legacy#mssql#sql#still
Discussion (46 Comments)Read Original on HackerNews
They blogged everything to generate the setup, including the hunch and test code but the anecdotal results are missing. It's a little suspect. How much faster is ARM??
1) They’d distract from the main point (I wasn’t aiming to write a benchmarking post), and
2) They can be misleading, since results will vary across ARM hardware and even between Snapdragon X Elite variants.
Instead, I included the PowerShell snippets so anyone interested can reproduce the results themselves.
For a rough sense of the outcome: the Snapdragon VM outperformed the Intel VM by ~20–80%, depending on the test (DNS ~20%, IIS ~50%, all others closer to ~80%).
A bit of backstory: there are two, totally independent implementations behind the Windows heap allocation APIs (i.e. the implementation code behind RtlHeapAlloc and RtlHeapFree, which are called by malloc/free). The older of the two, developed uring the Dave Cutler era, is known as the "NT heap". The newer implementation, developed in the 2010s, is known as "segment heap". This is all documented online if anyone wants to read more. When development on segment heap was completed, it was known to be superior to the NT heap in many ways. In particular, it was more efficient in terms of memory footprint, due to lower fragmentation-related waste. Segment heap was smarter about reusing small allocations slots that were recently free'd. But, as ever, Windows was very serious about legacy app compat. Joel Spolsky calls this the 'Raymond Chen camp'. So, they didn't want to turn segment heap on universally. It was known that a small portion of legacy software would misbehave and do things like, rely on doing a bit of use-after-free as a treat. Or worse, it took dependencies on casting addresses to internal NT heap data structures. So, the decision at the time was to make segment heap the default for packaged executables. At that time, Windows Phone still existed, and Microsoft was pushing super hard on the Universal platform being the new, recommended way to make apps on Windows. So they thought we'd see a gradual transition from unpackaged executables to packaged, and thus, a gradual transition from NT heap to segment heap. The dream of UWP died, and the Windows framework landscape is more fragmented than ever. Most important software on Windows is still unpackaged, and most of it runs on x64.
Why does this matter? Because segment heap is also enabled by default on arm. Same logic as the packaged vs unpackaged decision. Arm64 binaries on Windows are guaranteed not to be ancient, unmaintained legacy code. Arm64 windows devices have been a big success, and users widely report that they feel more responsive than x64 devices.
A not insignificant part of why Windows feels better on arm is because segment heap is enabled by default on arm.
I'd be interested to see how this test turns out if you force segment heap on x64. You can do it on a per-executable basis via creating a DWORD value named FrontEndHeapDebugOptions under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<myExeName>.exe, and giving it a value of 8.
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 do this on my dev machine and have encountered zero problems. The memory footprint savings are pretty crazy. About 15% in my testing.
However, reading the summary left me confused like you don't understand what's happening at Microsoft.
> Hopefully Microsoft will spend more time in the future on their server product strategy and less on Copilot ;-)
The future product strategy is clear, it's Linux for servers. .Net runs on Linux, generally with much better performance. Microsoft internally on Azure is using Linux a ton and Windows Server is legacy and hell, MSSQL is legacy. Sure, they will continue to sell it because if you want to give them thousands of dollars, they would be idiots to turn it down but it's no longer a focus.
It's not a dominant database anywhere on the outside.
However since we now got the tools for running on both, and experience migrating, we might be moving to PostgreSQL at some point in not too distant future. Managed MSSQL in Azure is not cheap.
I'd be curious what a better/non-legacy solution is! (as I do this stuff haha, and don't see much else other than full cloud options, sf etc)
Knowing nothing about this, I wonder if they're getting ready to retire Windows Server, and wanted to get their server products off it?
Edit: How they did it is also quite fascinating:
https://www.microsoft.com/en-us/sql-server/blog/2016/12/16/s...
https://www.microsoft.com/en-us/research/project/drawbridge/
>a key contribution of Drawbridge is a version of Windows that has been enlightened to run within a single Drawbridge picoprocess.
MSSQL on Linux only seems to use parts of that project (a smaller abstraction layer), but that's still super cool.
To give you an idea of how bad things have gotten, there's like one guy working on developer tooling for SQL Server and he's "too busy" to implement SDK-style SQL Server Data Projects for Visual Studio. He's distracted by, you guessed it, support for Fabric's dialect of SQL for which the only tooling is Visual Studio Code (not VS 2026).
There's people screaming at Microsoft that they have VS solutions with hundreds of .NET 10 and SQL projects, and now they can't open it their flagship IDE product because the SQL team office at Redmond has cloth draped over the furnite and the lights are all off except over one cubicle.
Also: There still isn't support for Microsoft Azure v6 or v7 virtual machines in Microsoft SQL Server because they just don't have the staff to keep up with the low-level code changes required to support SSD over NVMe with 8 KB atomicity. Think about how insanely understaffed they must be if they're unable to implement 8 KB cluster support in a database engine that uses 8 KB pages!!!
As somebody who's been procrastinating on getting my main project off of SSDT,
We can all tell.
Azure networking is Linux.
EDIT: Marvel at the NT4 style Task Manager [0].
[0] https://techcommunity.microsoft.com/blog/windowsosplatform/a...
https://www.phoronix.com/news/Linux-6.19-Improves-Hyper-V
Windows server is actually kind of awesome for when you need a Windows machine. Linux is great for servers but Windows server is the real Windows pro. Rock solid and none of the crap.
The worst part of Windows server is knowing that Microsoft can make a good operating system and chooses not to.
Could even enable XP themes IIRC.
Even Apple and Google run AD internally.
Gotta support all those CAD workstations running Windows.
Is Apple hardware still designed on Windows PCs?
Im not sure is CAD stuff is just served by a basic graphics card at this point or if there is some server side work going on.
OS doesnt mean that much when every industry decided that Chrome was going to be their VM
Our GIS clients run WS as a Deskstop OS with ESRIs ArcGIS Pro. Incredibly common.
And once you have that - add in Active directory, DFS and random Windows Servers for running archaic proprietary licensing services.
It's a beast in terms of complexity, in my opinion. But the vendor only supports running it on specific configurations.
You can recreate Windows Server on other platforms by stringing together bits and pieces, but there is nothing that comes even close in terms of integration and how everything works together. Nothing.
I know big company that run their core on Windows Server 2012, I’ve no idea how they manage the software assurance and compliance
(I know, I know. That question might be a bit too loaded. I'm really very sorry. No, there's no need that; I'll see myself out.)
mild \s
But you’re not going to do that in a lab/personal machine, usually.