EF6 vs EF Core 10: we draaiden dezelfde queries op allebei en hebben gemeten

“Is EF Core echt sneller, of staat dat alleen in de release notes?” Die vraag stelt elk team met een oude Entity Framework 6-applicatie voordat het beslist of de migratie de moeite waard is. Microsoft publiceert benchmarks, maar die lijken zelden op de queries in een echt order- of facturatiesysteem.

Dus schreven we de queries die zo’n systeem bevat, en draaiden we precies dezelfde op drie opstellingen: EF6 op .NET Framework 4.8, waar de meeste EF6-applicaties nog draaien, EF6 op .NET 10, wat kan sinds EF 6.4, en EF Core 10 op .NET 10. Dezelfde database, dezelfde data, dezelfde entityklassen.

Het korte antwoord: EF Core 10 was 1,6 tot 17 keer sneller dan EF6 op .NET Framework, en gebruikte tot 28 keer minder geheugen. Het grootste verschil zat in het opslaan van data, niet in het lezen. En EF6 op .NET 10 bleek een nuttige tussenstap: sneller dan op .NET Framework, zonder ook maar één query aan te passen.

Hoe we hebben gemeten

• De database: SQL Server (LocalDB) op dezelfde machine, met 1.000 klanten, 10.000 orders met een notitieveld van 2 KB en 50.000 orderregels. Een kwart van de orders staat open.
• Dezelfde entityklassen voor alle drie de opstellingen, gemapt op dezelfde tabellen. EF6 6.5.1 en EF Core 10.
• Het gereedschap: BenchmarkDotNet 0.15.8, met 3 opwarm- en 12 meetiteraties per geval, inclusief geheugenallocaties.
• Elk geval opent een nieuwe context, zoals een webrequest dat zou doen. Inserts en updates draaien in een transactie die wordt teruggedraaid, zodat elke iteratie dezelfde data ziet.
• De machine: een laptop met een Intel Core Ultra 7 255H.

De zeven bewerkingen:

Bewerking	Waar die voor staat
100 keer opzoeken op id, één voor één	Records één voor één laden in een scherm of een import
2.500 open orders laden, zonder tracking	Een alleen-lezen lijst of rapport
2.500 open orders laden, met tracking	Dezelfde lijst, zoals de meeste oudere code die laadt
Open orders projecteren naar een kleine klasse	Een lijstscherm zoals het hoort
100 orders laden met hun regels (Include)	Een orderdetail of een export
500 orders invoegen	Een import of een batchjob
200 orders laden en bijwerken	Een prijswijziging in bulk

De resultaten

Bewerking	EF6, .NET Framework 4.8	EF6, .NET 10	EF Core 10	EF Core 10 vs EF6 op 4.8
100 keer opzoeken op id	30,2 ms	17,1 ms	8,0 ms	3,8× sneller
2.500 orders, zonder tracking	58,3 ms	44,0 ms	24,4 ms	2,4× sneller
2.500 orders, met tracking	87,6 ms	59,3 ms	40,5 ms	2,2× sneller
Projectie naar een kleine klasse	9,0 ms	5,5 ms	5,8 ms	1,6× sneller
100 orders met regels	17,4 ms	13,6 ms	11,1 ms	1,6× sneller
500 orders invoegen	272,0 ms	127,7 ms	15,9 ms	17× sneller
200 orders bijwerken	22,4 ms	18,7 ms	6,6 ms	3,4× sneller

Het geheugengebruik ging dezelfde kant op, en soms veel verder:

Bewerking	EF6, .NET Framework 4.8	EF Core 10
100 keer opzoeken op id	7,1 MB	1,6 MB
2.500 orders, zonder tracking	31,2 MB	10,8 MB
2.500 orders, met tracking	37,3 MB	13,2 MB
500 orders invoegen	153,6 MB	5,4 MB
200 orders bijwerken	8,6 MB	2,5 MB

Eerlijk is eerlijk: de insertcijfers voor EF6 wisselden per run, van ongeveer 250 tot 330 ms op .NET Framework. De tabel toont de laatste run. Het verschil met EF Core was in elke run meer dan 15 keer.

Data opslaan: daar is het verschil het grootst

De insert is het meest opvallende getal, en het loont om te begrijpen waarom. Juist daar verliezen veel EF6-applicaties de meeste tijd, in imports en nachtelijke jobs.

for (var i = 0; i < 500; i++)
    db.Orders.Add(new Order { CustomerId = 1, Date = DateTime.Today, Total = 10m, Status = "New" });
db.SaveChanges();

Op beide dezelfde code. Twee dingen maken EF6 hier traag:

• EF6 stuurt één INSERT per rij. 500 orders zijn 500 losse commando’s naar de database. EF Core bundelt ze in een paar batches. Op een echte server via het netwerk voegt elk van die 500 round trips latency toe, dus het verschil wordt alleen maar groter.
• EF6 controleert bij elke Add alle gevolgde entities. Elke aanroep draait change detection over alles wat al in de context zit, dus veel entities toevoegen wordt trager naarmate het er meer zijn.

Voor het tweede punt is er in EF6 zelf een goedkope oplossing, en die is het kennen waard, ook als u nooit migreert:

db.Orders.AddRange(orders);
db.SaveChanges();

Met AddRange duurde dezelfde insert in EF6 op .NET Framework 80,9 ms in plaats van 272 ms, en werd er 21 MB gealloceerd in plaats van 154 MB. Nog steeds vijf keer trager dan EF Core, omdat de ene insert per rij blijft, maar een winst van 3× voor één gewijzigde regel. Heeft uw EF6-applicatie een import die rijen in een lus toevoegt? Begin daar.

Updates volgen hetzelfde patroon. EF Core stuurt de 200 updates in batches en de change tracker doet per entity minder werk. Dat levert 3,4 keer de snelheid op, met een derde van het geheugen.

Data lezen: gestage winst, en één verrassing

Bij het lezen was EF Core 10 1,6 tot 3,8 keer sneller. De grootste winst zat in veel kleine queries: 100 keer opzoeken op id kostte 30 ms in EF6 en 8 ms in EF Core. In EF Core heeft elke query veel minder overhead bij het vertalen en uitvoeren, en dat telt in code die veel kleine queries draait, zoals schermen die gerelateerde data record voor record laden.

De verrassing was de projectie. Als de query alleen de kolommen ophaalt die een scherm nodig heeft, was EF6 op .NET 10 even snel als EF Core 10: 5,5 ms tegen 5,8 ms. Het meeste werk gebeurt daar in de database, en beide sturen een vergelijkbare SQL-query. Projectie is op elke versie een goed advies, zoals ook bleek uit ons artikel over de vijf meest gemaakte EF Core-fouten.

EF6 op .NET 10: een nuttige tussenstap

Veel teams zien de migratie als één grote stap: van .NET Framework met EF6 naar .NET 10 met EF Core. Dat hoeft niet. EF6 draait sinds versie 6.4 op modern .NET, en in onze metingen werd het 1,2 tot 2,1 keer sneller door het alleen naar .NET 10 te verhuizen, zonder één query te wijzigen.

Dat maakt een route in twee stappen mogelijk:

1. Stap 1De applicatie naar .NET 10 verhuizen, EF6 behouden
2. Stap 2EF6 deel voor deel vervangen door EF Core

De eerste stap levert u een ondersteunde runtime op en een deel van de snelheid. De tweede kan daarna geleidelijk, te beginnen met de onderdelen die de meeste data opslaan of de meeste queries draaien. EF6 op modern .NET heeft zijn configuratie in code nodig in plaats van in app.config, en dat zijn maar een paar regels:

public class Ef6Configuration : DbConfiguration
{
    public Ef6Configuration()
    {
        SetProviderServices(SqlProviderServices.ProviderInvariantName, SqlProviderServices.Instance);
        SetProviderFactory(SqlProviderServices.ProviderInvariantName, SqlClientFactory.Instance);
    }
}

Er zijn grenzen: de EF6-designer werkt niet rechtstreeks in moderne .NET-projecten, dus modellen die uit EDMX-bestanden zijn opgebouwd vragen extra werk. En EF6 is stabiel en ondersteund, maar wordt niet meer actief doorontwikkeld. Het is een brug, geen eindbestemming. De volledige overstap, en wat die moeilijker of makkelijker maakt, leest u in ons artikel over de migratie van EF6 naar EF Core.

Wat dit in de praktijk betekent

Een paar milliseconden per query klinkt als weinig. Maar het telt op op de plekken die een bedrijf echt voelt:

• Imports en nachtelijke jobs. Bij een import van 50.000 rijen die in een lus invoegt, betekent die 17× dat uren minuten worden.
• Drukke schermen. Een scherm dat bij het laden 100 kleine queries draait, is per gebruiker elke keer 22 ms sneller, en de server doet een kwart van het allocatiewerk.
• Serverkosten. Minder geheugen per request betekent minder garbage collections en meer requests per server. Dat telt als u in Azure voor elke instance betaalt.

En in één opzicht zijn de cijfers een ondergrens: onze database draaide op dezelfde machine, dus er was geen netwerk. Op een echte SQL Server of Azure SQL kost elke round trip die EF6 maakt en EF Core vermijdt ook netwerklatency.

Hoeveel sneller gewone bedrijfscode op .NET 10 draait dan op .NET Framework, zonder database, leest u in onze meting van .NET Framework 4.8 vs .NET 10.

Vragen die we vaak horen

Is migreren van EF6 naar EF Core alleen voor de performance de moeite waard?

Meestal niet om de performance alleen. Maar performance is zelden de enige reden: EF6 krijgt geen nieuwe functies, en het houdt veel applicaties vast aan .NET Framework. Gaat u toch al naar .NET 10, dan hoort de datalaag uiteindelijk op EF Core te draaien. Begin met de onderdelen die de meeste data opslaan.

Kunnen we EF6 niet gewoon op .NET 10 draaien?

Ja, sinds EF 6.4. Applicaties waarvan het model in de EF6-designer uit een EDMX-bestand is opgebouwd, vragen eerst wat extra werk. In onze metingen was het 1,2 tot 2,1 keer sneller dan op .NET Framework. Een goede eerste stap, maar geen thuis voor de lange termijn.

Gelden deze resultaten ook op een echte SQL Server?

De richting wel. De exacte milliseconden hangen af van uw server, uw data en uw indexen. Bij inserts en updates wordt het verschil via een netwerk groter, omdat EF6 veel meer round trips maakt. Daarom loont het om uw eigen traagste bewerkingen vooraf en achteraf te meten.

Onze EF6-import is traag. Wat is de snelste winst?

Vervang Add in een lus door één AddRange, of zet de automatische change detection uit tijdens de import. In onze test maakte dat alleen al de EF6-insert drie keer sneller.

Hoe wij werken

Dit is precies wat wij doen. ProCoding is een .NET-studio uit Split, Kroatië, en we zetten .NET Framework-applicaties en hun EF6-datalaag over naar .NET 10 en EF Core: eerst meten, dan migreren in stappen die het bedrijf niet merkt, en elke stap controleren met cijfers. Zelf, met uw team of als freelance .NET developer in uw team. De eerste stap is een gratis gesprek van 30 minuten.

Bronnen

• BenchmarkDotNet, de benchmarktool die we gebruikten
• Port from EF6 to EF Core, Microsoft Learn
• Compare EF Core and EF6, Microsoft Learn
• Efficient updating, Microsoft Learn
• Onze eigen metingen, oktober 2026, zoals hierboven beschreven