.NET Framework 4.8 mot .NET 10: vi körde samma affärskod på båda
Vi mätte typisk affärskod på .NET Framework 4.8, .NET 8 och .NET 10: rapporter, uppslag, XML, fakturor, validering. Vad som blev snabbare och varför.
Vlado Pandžić · Grundare · Senior .NET-arkitekt
Publicerad · 7 min läsning
Innehåll
”Är .NET 10 verkligen snabbare, eller är det bara marknadsföring?” Det är en rimlig fråga inför en migrering som kostar riktiga pengar. Microsoft publicerar varje år långa listor med prestandaförbättringar, men de är skrivna för utvecklare och uppmätta på kod som ingen på ett företag känner igen.
Därför skrev vi vanlig affärskod, sådan som finns i varje order-, fakturerings- eller rapportsystem, och körde exakt samma kod på .NET Framework 4.8, .NET 8 och .NET 10.
Det korta svaret: på .NET 10 gick samma kod 1,7 till 14 gånger snabbare, i ett fall 35 gånger, med mindre minne och utan att en enda rad ändrades. Mellan .NET 8 och .NET 10 var vinsterna små. Det stora steget är att lämna .NET Framework.
Så mätte vi
- Koden: sex operationer på genererad data som ser ut som ett riktigt system: 100 000 order med kunder, datum, belopp och e-postadresser.
- Samma källfil, kompilerad för
net48,net8.0ochnet10.0, utan versionsspecifika ändringar. - Verktyget: BenchmarkDotNet 0.15.8, standardverktyget för att mäta prestanda i .NET. Det kör varje operation många gånger, kastar uppvärmningen och redovisar medelvärdet.
- Uppsättningen: x64, Release-bygge, 3 uppvärmningar och 12 uppmätta iterationer per operation, på en bärbar dator med Intel Core Ultra 7 255H.
De sex operationerna:
| Operation | Vad den motsvarar |
|---|---|
| Gruppera 100 000 order per kund och summera beloppen | En försäljningsrapport |
| Sortera 100 000 order på datum och belopp, ta den första | ”Den äldsta öppna ordern” |
| 200 000 uppslag i en dictionary på ordernummer | Matchning av importerad data |
| Formatera 10 000 fakturarader med datum och belopp | En export eller en utskrift |
| Validera 100 000 e-postadresser med ett reguljärt uttryck | Kontroll av inmatning |
| Skriva och läsa 2 000 order som XML | Gamla integrationer och SOAP-tjänster |
Resultaten
| Operation | .NET Framework 4.8 | .NET 8 | .NET 10 | .NET 10 mot 4.8 |
|---|---|---|---|---|
| Gruppera och summera 100 000 order | 12,7 ms | 7,5 ms | 7,4 ms | 1,7× snabbare |
| Sortera 100 000 order, ta den första | 21,9 ms | 0,77 ms | 0,63 ms | 35× snabbare |
| 200 000 uppslag i en dictionary | 31,9 ms | 17,7 ms | 17,8 ms | 1,8× snabbare |
| Formatera 10 000 fakturarader | 3,6 ms | 1,05 ms | 0,94 ms | 3,9× snabbare |
| Validera 100 000 e-postadresser | 70,5 ms | 5,6 ms | 5,2 ms | 13,6× snabbare |
| Skriva och läsa 2 000 order som XML | 5,7 ms | 3,2 ms | 2,9 ms | 1,9× snabbare |
Minnet gick åt samma håll. Formateringen av fakturaraderna allokerade 41 % mindre minne på .NET 10, XML-rundan 36 % mindre, och sorteringen gick från 3,6 MB allokeringar till nästan ingenting.
Varför det blev snabbare
Inget av detta kom från att vi ändrade vår kod. Det kom från tre ställen i själva .NET:
- En bättre JIT-kompilator. Modern .NET kompilerar het kod två gånger: snabbt först, sedan igen med optimeringar baserade på hur koden faktiskt körs (dynamic profile-guided optimization). Vanliga loopar och LINQ blir snabbare utan att någon märker det.
- En omskriven motor för reguljära uttryck. Regex i modern .NET byggdes om för hastighet. Vår e-postvalidering gick från 70 ms till 5 ms, den största vinsten i vanlig kod.
- Smartare bibliotek. De 35× i sorteringen beror inte på att processorn jobbar snabbare. LINQ i modern .NET känner igen att
OrderBy(...).First()bara behöver det minsta elementet och hittar det utan att sortera alla 100 000 order. På .NET Framework sorteras hela listan först.
Den sista punkten är värd att komma ihåg: en del av de största vinsterna kommer från att biblioteken gör mindre arbete, inte från snabbare hårdvara eller en snabbare runtime.
.NET 8 eller .NET 10?
Mellan .NET 8 och .NET 10 låg skillnaderna i vårt test på mellan 0 och 18 %, ibland inom mätbruset. Kör du .NET 8 är skälet att gå till .NET 10 supporten, som upphör den 10 november 2026, inte hastigheten. Det tar vi upp i vår artikel om att supporten för .NET 8 och 9 upphör.
Vi lämnade release candidate-versionen av .NET 11 utanför tabellen, eftersom mätverktyget ännu inte kunde köra den på samma sätt som de andra. Vi lägger till den slutliga versionen när den kommer i november.
Vad det betyder för ett företag
Snabbare kod betyder inte automatiskt en snabbare applikation. En typisk webbförfrågan lägger mycket av sin tid på att vänta på databasen, nätverket eller ett annat system, och de väntetiderna ändras inte med .NET-versionen. Men det arbete servern gör själv blir snabbare:
- Rapporter och exporter som bearbetar data i minnet blir klara tidigare.
- Importer och nattliga jobb som validerar, omvandlar och matchar data körs på en bråkdel av tiden.
- Samma server klarar fler användare, vilket i molnet kan betyda en mindre och billigare plan.
- Gamla integrationer som serialiserar XML kostar mindre CPU per anrop.
Om din .NET Framework-applikation är långsam på grund av databasfrågor löser en migrering ensam inte det. Vår artikel om vad du gör med en långsam applikation visar var du ska titta först.
Ska du migrera bara för hastighetens skull?
Sällan. En migrering från .NET Framework är ett riktigt arbete, och hastigheten är oftast en välkommen bieffekt, inte skälet. Skälen är oftast:
- Support och säkerhet. .NET Framework 4.8 får support som en del av Windows, men inga nya funktioner, och resten av ekosystemet har gått vidare.
- Människor. Utvecklare vill arbeta med modern .NET, och det blir svårare för varje år att rekrytera till gammal kod.
- Drift. Modern .NET körs på Linux, i containrar och i billigare molnplaner.
Men när ett system bearbetar stora mängder data, som importer, rapporter eller valideringar, kan hastighetsskillnaden betala en stor del av migreringen genom mindre servrar och kortare nattkörningar. Hur du planerar den står i vår artikel om att migrera från .NET Framework till .NET 10.
Frågor vi ofta får
Blir min applikation så här mycket snabbare?
Inte som helhet. Siffrorna gäller det arbete processorn gör i din kod. Om det mesta av tiden går åt till att vänta på databasen blir den totala vinsten mindre. Det bästa sättet att veta är att mäta dina egna långsammaste operationer före och efter.
Måste vi ändra koden för att få uppsnabbningen?
För det mesta inte. Vår testkod var identisk i alla tre versionerna. Vinsterna kom från runtime och bibliotek. Med nyare API:er går det att vinna ännu mer, men det är frivilligt.
Är testet rättvist mot .NET Framework?
Vi använde samma källkod, samma data och samma maskin för alla tre, och standardverktyget för prestandamätning. Vi använde inget som bara finns i modern .NET. Om något är det den mest gynnsamma uppsättningen för .NET Framework, eftersom kod skriven för modern .NET skulle använda snabbare API:er.
Kan vi få se koden?
Koden är kort, och vi skickar den gärna. Fråga under det kostnadsfria samtalet, eller pröva samma idé på dina egna långsammaste operationer.
Så arbetar vi
Det här är precis vad vi gör. ProCoding är en .NET-studio i Split, Kroatien, och vi flyttar .NET Framework-applikationer till modern .NET en del i taget, med mätningar före och efter så att du ser vad flytten gav. Mer om vårt arbete med .NET och Blazor. Första steget: Boka ett kostnadsfritt samtal på 30 minuter.
Källor
- BenchmarkDotNet, mätverktyget vi använde
- 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 och profile-guided optimization)
- Egna mätningar, oktober 2026, enligt beskrivningen ovan
Den här artikeln är endast allmän information och inte juridisk, skattemässig, ekonomisk eller annan professionell rådgivning. Scenarier, exempel och beräkningar är illustrativa. Användarvillkor och ansvarsfriskrivning.