.NET Framework 4.8 vs .NET 10: derselbe Geschäftscode auf beiden gemessen
Typischer Geschäftscode auf .NET Framework 4.8, .NET 8 und .NET 10 gemessen: Berichte, Suchen, XML, Rechnungen, Validierung. Was schneller wurde und warum.
Vlado Pandžić · Gründer · Senior .NET-Architekt
Veröffentlicht · 7 Min. Lesezeit
Inhalt
„Ist .NET 10 wirklich schneller, oder ist das nur Marketing?“ Eine berechtigte Frage vor einer Migration, die echtes Geld kostet. Microsoft veröffentlicht jedes Jahr lange Listen mit Leistungsverbesserungen, aber sie sind für Entwickler geschrieben und an Code gemessen, den in einem Unternehmen niemand wiedererkennt.
Also haben wir gewöhnlichen Geschäftscode geschrieben, wie er in jedem Bestell-, Rechnungs- oder Berichtssystem steckt, und genau denselben Code auf .NET Framework 4.8, .NET 8 und .NET 10 laufen lassen.
Die kurze Antwort: Auf .NET 10 lief derselbe Code 1,7- bis 14-mal schneller, in einem Fall sogar 35-mal, mit weniger Speicher und ohne eine einzige geänderte Zeile. Zwischen .NET 8 und .NET 10 waren die Unterschiede klein. Der große Schritt ist der Abschied von .NET Framework.
Wie wir gemessen haben
- Der Code: sechs Operationen auf generierten Daten, die wie ein echtes System aussehen: 100.000 Bestellungen mit Kunden, Datum, Beträgen und E-Mail-Adressen.
- Dieselbe Quelldatei, kompiliert für
net48,net8.0undnet10.0, ohne versionsspezifische Anpassungen. - Das Werkzeug: BenchmarkDotNet 0.15.8, das Standardwerkzeug zur Leistungsmessung in .NET. Es führt jede Operation viele Male aus, verwirft das Aufwärmen und gibt den Durchschnitt aus.
- Der Aufbau: x64, Release-Build, 3 Aufwärm- und 12 Messdurchläufe pro Operation, auf einem Laptop mit Intel Core Ultra 7 255H.
Die sechs Operationen:
| Operation | Wofür sie steht |
|---|---|
| 100.000 Bestellungen nach Kunde gruppieren und Beträge summieren | Ein Umsatzbericht |
| 100.000 Bestellungen nach Datum und Betrag sortieren, die erste nehmen | „Die älteste offene Bestellung“ |
| 200.000 Dictionary-Suchen nach Bestellnummer | Abgleich importierter Daten |
| 10.000 Rechnungspositionen mit Datum und Betrag formatieren | Ein Export oder Ausdruck |
| 100.000 E-Mail-Adressen mit einem regulären Ausdruck prüfen | Eingabevalidierung |
| 2.000 Bestellungen als XML schreiben und lesen | Alte Schnittstellen und SOAP-Dienste |
Die Ergebnisse
| Operation | .NET Framework 4.8 | .NET 8 | .NET 10 | .NET 10 gegenüber 4.8 |
|---|---|---|---|---|
| 100.000 Bestellungen gruppieren und summieren | 12,7 ms | 7,5 ms | 7,4 ms | 1,7× schneller |
| 100.000 Bestellungen sortieren, die erste nehmen | 21,9 ms | 0,77 ms | 0,63 ms | 35× schneller |
| 200.000 Dictionary-Suchen | 31,9 ms | 17,7 ms | 17,8 ms | 1,8× schneller |
| 10.000 Rechnungspositionen formatieren | 3,6 ms | 1,05 ms | 0,94 ms | 3,9× schneller |
| 100.000 E-Mail-Adressen prüfen | 70,5 ms | 5,6 ms | 5,2 ms | 13,6× schneller |
| 2.000 Bestellungen als XML schreiben und lesen | 5,7 ms | 3,2 ms | 2,9 ms | 1,9× schneller |
Der Speicher entwickelte sich in dieselbe Richtung. Das Formatieren der Rechnungspositionen belegte auf .NET 10 41 % weniger Speicher, das Schreiben und Lesen von XML 36 % weniger, und das Sortieren ging von 3,6 MB Allokationen auf fast nichts zurück.
Warum es schneller wurde
Nichts davon kam von Änderungen an unserem Code. Es kam aus drei Stellen in .NET selbst:
- Ein besserer JIT-Compiler. Modernes .NET kompiliert häufig genutzten Code zweimal: zuerst schnell, dann erneut mit Optimierungen, die darauf beruhen, wie der Code tatsächlich läuft (dynamische profilgesteuerte Optimierung). Einfache Schleifen und LINQ profitieren davon, ohne dass es jemand merkt.
- Eine neu geschriebene Engine für reguläre Ausdrücke. Regex wurde in modernem .NET auf Geschwindigkeit hin neu gebaut. Unsere E-Mail-Validierung fiel von 70 ms auf 5 ms, der größte Gewinn in gewöhnlichem Code.
- Klügere Bibliotheken. Die 35× beim Sortieren bedeuten nicht, dass der Prozessor schneller arbeitet. LINQ in modernem .NET erkennt, dass
OrderBy(...).First()nur das kleinste Element braucht, und findet es, ohne alle 100.000 Bestellungen zu sortieren. Auf .NET Framework wird zuerst die ganze Liste sortiert.
Der letzte Punkt ist es wert, ihn sich zu merken: Einige der größten Gewinne entstehen, weil die Bibliotheken weniger Arbeit machen, nicht durch schnellere Hardware oder eine schnellere Runtime.
.NET 8 oder .NET 10?
Zwischen .NET 8 und .NET 10 lagen die Unterschiede in unserem Test zwischen 0 und 18 %, teils innerhalb des Messrauschens. Wenn Sie auf .NET 8 sind, ist der Grund für den Umstieg auf .NET 10 der Support, der am 10. November 2026 endet, nicht die Geschwindigkeit. Mehr dazu in unserem Artikel zum Support-Ende von .NET 8 und 9.
Den Release Candidate von .NET 11 haben wir aus der Tabelle herausgelassen, weil das Messwerkzeug ihn noch nicht auf dieselbe Weise ausführen konnte wie die anderen. Die finale Version ergänzen wir, sobald sie im November erscheint.
Was das für ein Unternehmen bedeutet
Schnellerer Code bedeutet nicht automatisch eine schnellere Anwendung. Eine typische Webanfrage verbringt viel Zeit mit Warten auf die Datenbank, das Netzwerk oder ein anderes System, und diese Wartezeiten ändern sich mit der .NET-Version nicht. Aber die Arbeit, die der Server selbst erledigt, wird schneller:
- Berichte und Exporte, die Daten im Speicher verarbeiten, sind früher fertig.
- Importe und nächtliche Jobs, die Daten prüfen, umwandeln und abgleichen, brauchen einen Bruchteil der Zeit.
- Derselbe Server bedient mehr Benutzer, was in der Cloud einen kleineren, günstigeren Tarif bedeuten kann.
- Alte Schnittstellen, die XML serialisieren, verbrauchen pro Aufruf weniger CPU.
Wenn Ihre .NET-Framework-Anwendung wegen Datenbankabfragen langsam ist, wird eine Migration allein das nicht beheben. Unser Artikel dazu, was zu tun ist, wenn eine Anwendung langsam ist, zeigt, wo Sie zuerst hinschauen sollten.
Lohnt sich eine Migration allein wegen der Geschwindigkeit?
Selten. Eine Migration von .NET Framework ist echte Arbeit, und Geschwindigkeit ist meist ein willkommener Nebeneffekt, nicht der Grund. Die Gründe sind meistens:
- Support und Sicherheit. .NET Framework 4.8 wird als Teil von Windows unterstützt, bekommt aber keine neuen Funktionen, und der Rest des Ökosystems ist weitergezogen.
- Personal. Entwickler wollen mit modernem .NET arbeiten, und für alten Code wird es jedes Jahr schwerer, Leute zu finden.
- Hosting. Modernes .NET läuft unter Linux, in Containern und in günstigeren Cloud-Tarifen.
Wenn ein System aber große Datenmengen, Importe, Berichte oder Validierungen verarbeitet, kann der Geschwindigkeitsunterschied durch kleinere Server und kürzere Nachtläufe einen guten Teil der Migration bezahlen. Wie man sie plant, steht in unserem Artikel zum Umstieg von .NET Framework auf .NET 10.
Fragen, die wir oft hören
Wird meine Anwendung so viel schneller?
Nicht als Ganzes. Diese Zahlen betreffen die Arbeit, die der Prozessor in Ihrem Code erledigt. Wenn die meiste Zeit auf das Warten auf die Datenbank entfällt, fällt der Gesamtgewinn kleiner aus. Am besten messen Sie Ihre eigenen langsamsten Operationen vorher und nachher.
Müssen wir den Code ändern, um die Beschleunigung zu bekommen?
Für den Großteil nicht. Unser Testcode war auf allen drei Versionen identisch. Die Gewinne kamen von der Runtime und den Bibliotheken. Mit neueren APIs ist noch mehr möglich, das ist aber optional.
Ist der Test fair gegenüber .NET Framework?
Wir haben für alle drei denselben Quellcode, dieselben Daten, dieselbe Maschine und das Standardwerkzeug zur Messung verwendet. Wir haben nichts genutzt, was es nur in modernem .NET gibt. Wenn überhaupt, ist das der günstigste Aufbau für .NET Framework, denn Code, der für modernes .NET geschrieben ist, würde schnellere APIs nutzen.
Können wir den Code sehen?
Der Code ist kurz, und wir schicken ihn Ihnen gern. Fragen Sie im kostenlosen Gespräch danach, oder wenden Sie dieselbe Idee auf Ihre eigenen langsamsten Operationen an.
Wie wir arbeiten
Genau das machen wir. ProCoding ist ein .NET-Studio in Split, Kroatien, und wir bringen .NET-Framework-Anwendungen Stück für Stück auf modernes .NET, mit Messungen vorher und nachher, damit Sie sehen, was der Umstieg gebracht hat. Mehr über unsere Arbeit mit .NET und Blazor. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.
Quellen
- BenchmarkDotNet, das Messwerkzeug, das wir verwendet haben
- Performance improvements in .NET 10, .NET Blog, Microsoft
- Regular expression improvements in .NET 7, .NET Blog, Microsoft
- Runtime configuration options for compilation, Microsoft Learn (gestufte Kompilierung und profilgesteuerte Optimierung)
- Eigene Messungen, Oktober 2026, wie oben beschrieben
Dieser Artikel dient nur der allgemeinen Information und ist keine Rechts-, Steuer-, Finanz- oder sonstige Fachberatung. Szenarien, Beispiele und Berechnungen dienen der Veranschaulichung. Nutzungsbedingungen und Haftungsausschluss.