.NET Framework 4.8 ili .NET 10: isti poslovni kod pokrenuli smo na oba
Izmjerili smo tipičan poslovni kod na .NET Frameworku 4.8, .NET-u 8 i .NET-u 10: izvještaje, pretrage, XML, račune i validaciju. Što je brže i zašto.
Vlado Pandžić · Osnivač · Senior .NET arhitekt
Objavljeno · 6 min čitanja
Sadržaj
„Je li .NET 10 stvarno brži ili je to samo marketing?” Pošteno pitanje prije migracije koja košta pravi novac. Microsoft svake godine objavi duge popise poboljšanja performansi, ali pisani su za programere i mjereni na kodu koji nitko u poslovnom svijetu ne bi prepoznao.
Zato smo napisali običan poslovni kod, onakav kakav ima svaki sustav za narudžbe, fakturiranje ili izvještaje, i pokrenuli potpuno isti kod na .NET Frameworku 4.8, .NET-u 8 i .NET-u 10.
Kratki odgovor: na .NET-u 10 isti je kod radio 1,7 do 14 puta brže, a u jednom slučaju čak 35 puta, uz manje memorije i bez promjene ijedne linije. Između .NET-a 8 i .NET-a 10 razlike su bile male. Veliki korak je odlazak s .NET Frameworka.
Kako smo mjerili
- Kod: šest operacija na generiranim podacima koji izgledaju kao pravi sustav: 100.000 narudžbi s kupcima, datumima, iznosima i e-mail adresama.
- Ista izvorna datoteka prevedena za
net48,net8.0inet10.0, bez ikakvih prilagodbi za pojedinu verziju. - Alat: BenchmarkDotNet 0.15.8, standardni alat za mjerenje performansi u .NET-u. Svaku operaciju pokreće mnogo puta, odbacuje zagrijavanje i daje prosjek.
- Postav: x64, Release build, 3 iteracije zagrijavanja i 12 mjerenih po operaciji, na laptopu s procesorom Intel Core Ultra 7 255H.
Šest operacija:
| Operacija | Što predstavlja |
|---|---|
| Grupiranje 100.000 narudžbi po kupcu i zbrajanje iznosa | Izvještaj o prodaji |
| Sortiranje 100.000 narudžbi po datumu i iznosu, uzimanje prve | „Najstarija otvorena narudžba” |
| 200.000 pretraga rječnika po broju narudžbe | Uparivanje uvezenih podataka |
| Formatiranje 10.000 stavki računa s datumima i iznosima | Izvoz ili ispis |
| Validacija 100.000 e-mail adresa regularnim izrazom | Provjera unosa |
| Zapisivanje i čitanje 2.000 narudžbi kao XML | Stare integracije i SOAP servisi |
Rezultati
| Operacija | .NET Framework 4.8 | .NET 8 | .NET 10 | .NET 10 prema 4.8 |
|---|---|---|---|---|
| Grupiranje i zbrajanje 100.000 narudžbi | 12,7 ms | 7,5 ms | 7,4 ms | 1,7× brže |
| Sortiranje 100.000 narudžbi, uzimanje prve | 21,9 ms | 0,77 ms | 0,63 ms | 35× brže |
| 200.000 pretraga rječnika | 31,9 ms | 17,7 ms | 17,8 ms | 1,8× brže |
| Formatiranje 10.000 stavki računa | 3,6 ms | 1,05 ms | 0,94 ms | 3,9× brže |
| Validacija 100.000 e-mail adresa | 70,5 ms | 5,6 ms | 5,2 ms | 13,6× brže |
| Zapisivanje i čitanje 2.000 narudžbi kao XML | 5,7 ms | 3,2 ms | 2,9 ms | 1,9× brže |
Memorija je išla u istom smjeru. Formatiranje stavki računa na .NET-u 10 zauzelo je 41 % manje memorije, XML zapis i čitanje 36 % manje, a sortiranje je s 3,6 MB alokacija palo na gotovo ništa.
Zašto je brže
Ništa od ovoga nije došlo od promjene našeg koda. Došlo je s tri mjesta u samom .NET-u:
- Bolji JIT prevoditelj. Moderni .NET prevodi često korišteni kod dvaput: prvo brzo, a zatim ponovno s optimizacijama prema tome kako se kod stvarno izvodi (dinamička optimizacija vođena profilom). Obične petlje i LINQ od toga dobivaju, a da nitko ništa ne primijeti.
- Iznova napisan mehanizam za regularne izraze. Regex je u modernom .NET-u izgrađen iznova, s naglaskom na brzinu. Naša validacija e-mail adresa pala je sa 70 ms na 5 ms, što je najveći dobitak u običnom kodu.
- Pametnije biblioteke. Onih 35× kod sortiranja nije procesor koji radi brže. LINQ u modernom .NET-u prepoznaje da
OrderBy(...).First()treba samo najmanji element i pronalazi ga bez sortiranja svih 100.000 narudžbi. Na .NET Frameworku najprije se sortira cijeli popis.
Ovo zadnje vrijedi zapamtiti: neki od najvećih dobitaka dolaze od toga što biblioteke rade manje posla, a ne od bržeg hardvera ili bržeg runtimea.
.NET 8 ili .NET 10?
Između .NET-a 8 i .NET-a 10 razlike su u našem testu bile od 0 do 18 %, ponekad unutar mjernog šuma. Ako ste na .NET-u 8, razlog za prelazak na .NET 10 je podrška, koja završava 10. studenoga 2026., a ne brzina. O tome više u našem članku o kraju podrške za .NET 8 i 9.
Release candidate .NET-a 11 izostavili smo iz tablice jer ga alat za mjerenje još nije mogao pokrenuti na isti način kao ostale. Konačnu verziju dodat ćemo kad izađe u studenome.
Što to znači za poslovanje
Brži kod ne znači automatski i bržu aplikaciju. Tipičan web zahtjev velik dio vremena čeka bazu, mrežu ili neki drugi sustav, a to čekanje ne ovisi o verziji .NET-a. Ali posao koji poslužitelj radi sam postaje brži:
- Izvještaji i izvozi koji obrađuju podatke u memoriji završavaju prije.
- Uvozi i noćni poslovi koji provjeravaju, pretvaraju i uparuju podatke traju djelić dosadašnjeg vremena.
- Isti poslužitelj podnosi više korisnika, što u oblaku može značiti manji i jeftiniji paket.
- Stare integracije koje serijaliziraju XML troše manje procesora po pozivu.
Ako je vaša .NET Framework aplikacija spora zbog upita prema bazi, sama migracija to neće riješiti. Naš članak o tome što napraviti kad je aplikacija spora pokazuje gdje prvo gledati.
Isplati li se migrirati samo zbog brzine?
Rijetko. Migracija s .NET Frameworka je ozbiljan posao, a brzina je obično dobrodošla nuspojava, ne razlog. Razlozi su najčešće:
- Podrška i sigurnost. .NET Framework 4.8 podržan je kao dio Windowsa, ali ne dobiva nove mogućnosti, a ostatak ekosustava otišao je dalje.
- Ljudi. Programeri žele raditi na modernom .NET-u, a za stari kod svake je godine teže zaposliti nekoga.
- Hosting. Moderni .NET radi na Linuxu, u kontejnerima i na jeftinijim paketima u oblaku.
No kad sustav obrađuje velike količine podataka, uvoze, izvještaje ili validacije, razlika u brzini može kroz manje poslužitelje i kraće noćne obrade vratiti dobar dio troška migracije. Kako je planirati, opisali smo u članku o prelasku s .NET Frameworka na .NET 10.
Pitanja koja najčešće čujemo
Hoće li moja aplikacija biti toliko brža?
Ne u cjelini. Ovi brojevi odnose se na posao koji procesor radi u vašem kodu. Ako većina vremena odlazi na čekanje baze, ukupni dobitak bit će manji. Najbolje je izmjeriti vlastite najsporije operacije prije i poslije.
Moramo li mijenjati kod da bismo dobili ubrzanje?
Za većinu ne. Naš testni kod bio je identičan na sve tri verzije. Dobitak je došao od runtimea i biblioteka. Dodatni dobici mogući su s novijim API-jima, ali to nije obavezno.
Je li test pošten prema .NET Frameworku?
Za sve tri verzije koristili smo isti izvorni kod, iste podatke, isto računalo i standardni alat za mjerenje. Nismo koristili ništa što postoji samo u modernom .NET-u. Ako ništa drugo, to je najpovoljniji postav za .NET Framework, jer bi kod pisan za moderni .NET koristio brže API-je.
Možemo li vidjeti kod?
Kod je kratak i rado ćemo vam ga poslati. Pitajte na besplatnom razgovoru ili primijenite istu ideju na vlastite najsporije operacije.
Kako mi radimo
Upravo to radimo. ProCoding je .NET studio iz Splita i .NET Framework aplikacije prebacujemo na moderni .NET dio po dio, uz mjerenje prije i poslije, tako da vidite što vam je prelazak donio. Više o našem radu s .NET-om i Blazorom. Prvi korak je besplatan razgovor od 30 minuta.
Izvori
- BenchmarkDotNet, alat za mjerenje koji smo koristili
- Performance improvements in .NET 10, .NET Blog, Microsoft
- Regular expression improvements in .NET 7, .NET Blog, Microsoft
- Runtime configuration options for compilation, Microsoft Learn (višerazinsko prevođenje i optimizacija vođena profilom)
- Naša mjerenja, listopad 2026., opisana gore
Ovaj članak služi općem informiranju i nije pravni, porezni, financijski ni drugi stručni savjet. Scenariji, primjeri i izračuni su ilustrativni. Uvjeti korištenja i odricanje od odgovornosti.