.NET Framework 4.8 vs .NET 10: we draaiden dezelfde zakelijke code op beide

“Is .NET 10 echt sneller, of is dat vooral marketing?” Een terechte vraag vóór een migratie die echt geld kost. Microsoft publiceert elk jaar lange lijsten met prestatieverbeteringen, maar die zijn geschreven voor ontwikkelaars en gemeten op code die niemand in een bedrijf herkent.

Daarom schreven we gewone zakelijke code, het soort dat in elk order-, facturatie- of rapportagesysteem zit, en draaiden we precies dezelfde code op .NET Framework 4.8, .NET 8 en .NET 10.

Het korte antwoord: op .NET 10 liep dezelfde code 1,7 tot 14 keer sneller, en in één geval 35 keer, met minder geheugen, zonder één regel aan te passen. Tussen .NET 8 en .NET 10 was de winst klein. De grote stap is het afscheid van .NET Framework.

Hoe we hebben gemeten

• De code: zes bewerkingen op gegenereerde data die eruitziet als een echt systeem: 100.000 orders met klanten, datums, totalen en e-mailadressen.
• Hetzelfde bronbestand, gecompileerd voor net48, net8.0 en net10.0, zonder versiespecifieke aanpassingen.
• Het gereedschap: BenchmarkDotNet 0.15.8, de standaardtool om .NET-prestaties te meten. Het draait elke bewerking vele keren, laat de opwarmrondes weg en rapporteert het gemiddelde.
• De opstelling: x64, Release-build, 3 opwarmrondes en 12 gemeten iteraties per bewerking, op een laptop met een Intel Core Ultra 7 255H.

De zes bewerkingen:

Bewerking	Waar het voor staat
100.000 orders groeperen per klant en de totalen optellen	Een verkooprapport
100.000 orders sorteren op datum en totaal, de eerste nemen	“De oudste openstaande order”
200.000 opzoekingen in een dictionary op ordernummer	Geïmporteerde data koppelen
10.000 factuurregels opmaken met datums en bedragen	Een export of een afdruk
100.000 e-mailadressen valideren met een reguliere expressie	Invoercontrole
2.000 orders als XML schrijven en lezen	Oude koppelingen en SOAP-services

De resultaten

Bewerking	.NET Framework 4.8	.NET 8	.NET 10	.NET 10 vs 4.8
100.000 orders groeperen en optellen	12,7 ms	7,5 ms	7,4 ms	1,7× sneller
100.000 orders sorteren, de eerste nemen	21,9 ms	0,77 ms	0,63 ms	35× sneller
200.000 opzoekingen in een dictionary	31,9 ms	17,7 ms	17,8 ms	1,8× sneller
10.000 factuurregels opmaken	3,6 ms	1,05 ms	0,94 ms	3,9× sneller
100.000 e-mailadressen valideren	70,5 ms	5,6 ms	5,2 ms	13,6× sneller
2.000 orders als XML schrijven en lezen	5,7 ms	3,2 ms	2,9 ms	1,9× sneller

Het geheugengebruik ging dezelfde kant op. Het opmaken van de factuurregels gebruikte op .NET 10 41 % minder geheugen, de XML-heen-en-terugreis 36 % minder, en het sorteren ging van 3,6 MB aan allocaties naar bijna niets.

Waarom het sneller werd

Niets hiervan kwam doordat we onze code veranderden. Het kwam uit drie plekken in .NET zelf:

• Een betere JIT-compiler. Modern .NET compileert veelgebruikte code twee keer: eerst snel, daarna opnieuw met optimalisaties op basis van hoe de code werkelijk draait (dynamic profile-guided optimization). Gewone lussen en LINQ profiteren daarvan zonder dat iemand het merkt.
• Een herschreven engine voor reguliere expressies. Regex is in modern .NET opnieuw gebouwd voor snelheid. Onze e-mailvalidatie ging van 70 ms naar 5 ms, de grootste winst in gewone code.
• Slimmere bibliotheken. De 35× bij het sorteren komt niet doordat de processor harder werkt. LINQ in modern .NET herkent dat OrderBy(...).First() alleen het kleinste element nodig heeft en vindt dat zonder alle 100.000 orders te sorteren. Op .NET Framework wordt eerst de hele lijst gesorteerd.

Dat laatste is het onthouden waard: een deel van de grootste winst komt doordat de bibliotheken minder werk doen, niet van snellere hardware of een snellere runtime.

.NET 8 of .NET 10?

Tussen .NET 8 en .NET 10 lagen de verschillen in onze test tussen 0 en 18 %, soms binnen de meetruis. Zit u op .NET 8, dan is de reden om naar .NET 10 te gaan de ondersteuning, die op 10 november 2026 afloopt, niet de snelheid. Daarover gaat ons artikel over het einde van de ondersteuning voor .NET 8 en 9.

De release candidate van .NET 11 hebben we buiten de tabel gelaten, omdat de benchmarktool die nog niet op dezelfde manier kon draaien als de andere. We voegen de definitieve versie toe zodra die in november uitkomt.

Wat het betekent voor een bedrijf

Snellere code betekent niet automatisch een snellere applicatie. Een typisch webverzoek besteedt veel van zijn tijd aan wachten op de database, het netwerk of een ander systeem, en dat wachten verandert niet met de .NET-versie. Maar het werk dat de server zelf doet, wordt wel sneller:

• Rapporten en exports die data in het geheugen verwerken, zijn eerder klaar.
• Imports en nachtelijke taken die data valideren, omzetten en koppelen, draaien in een fractie van de tijd.
• Dezelfde server bedient meer gebruikers, wat in de cloud een kleiner, goedkoper abonnement kan betekenen.
• Oude koppelingen die XML serialiseren, kosten minder CPU per aanroep.

Is uw .NET Framework-applicatie traag door databasequery’s, dan lost een migratie alleen dat niet op. Ons artikel over een trage applicatie oplossen laat zien waar u eerst moet kijken.

Moet u alleen voor de snelheid migreren?

Zelden. Een migratie van .NET Framework is echt werk, en snelheid is meestal een welkome bijkomstigheid, niet de reden. De redenen zijn meestal:

• Ondersteuning en beveiliging. .NET Framework 4.8 wordt ondersteund als onderdeel van Windows, maar krijgt geen nieuwe functies, en de rest van het ecosysteem is verdergegaan.
• Mensen. Ontwikkelaars willen met modern .NET werken, en het wordt elk jaar moeilijker om mensen te vinden voor oude code.
• Hosting. Modern .NET draait op Linux, in containers en in goedkopere cloudabonnementen.

Maar wanneer een systeem grote hoeveelheden data verwerkt, zoals imports, rapporten of validaties, kan het snelheidsverschil een flink deel van de migratie terugverdienen via kleinere servers en kortere nachtelijke runs. Hoe u dat plant, leest u in ons artikel over migreren van .NET Framework naar .NET 10.

Vragen die we vaak horen

Wordt mijn applicatie zoveel sneller?

Niet als geheel. Deze cijfers gaan over het werk dat de processor in uw code doet. Gaat de meeste tijd op aan wachten op de database, dan is de totale winst kleiner. De beste manier om het te weten is uw eigen traagste bewerkingen te meten, voor en na.

Moeten we de code aanpassen om de versnelling te krijgen?

Voor het grootste deel niet. Onze testcode was op alle drie de versies identiek. De winst kwam uit de runtime en de bibliotheken. Met nieuwere API’s valt er nog meer te halen, maar dat is optioneel.

Is de test eerlijk tegenover .NET Framework?

We gebruikten voor alle drie dezelfde broncode, dezelfde data en dezelfde machine, en de standaardtool voor benchmarks. We gebruikten niets wat alleen in modern .NET bestaat. Zo bekeken is het eerder de gunstigste opstelling voor .NET Framework, want code die voor modern .NET is geschreven, zou snellere API’s gebruiken.

Kunnen we de code zien?

De code is kort en we sturen hem graag op. Vraag ernaar in het gratis gesprek, of pas hetzelfde idee toe op uw eigen traagste bewerkingen.

Hoe wij werken

Dit is precies wat wij doen. ProCoding is een .NET-studio in Split, Kroatië, en we brengen .NET Framework-applicaties stap voor stap naar modern .NET, met metingen vooraf en achteraf, zodat u ziet wat de overstap heeft opgeleverd. Meer over ons .NET- en Blazor-werk. De eerste stap is een gratis gesprek van 30 minuten.

Bronnen

• BenchmarkDotNet, de benchmarktool die we gebruikten
• Performance improvements in .NET 10, .NET Blog, Microsoft
• Regular expression improvements in .NET 7, .NET Blog, Microsoft
• Runtime configuration options for compilation, Microsoft Learn (tiered compilation en profile-guided optimization)
• Eigen metingen, oktober 2026, zoals hierboven beschreven