EF6 mot EF Core 10: vi körde samma frågor på båda och mätte

”Är EF Core verkligen snabbare, eller är det bara vad releaseanteckningarna säger?” Det är frågan varje team med en äldre Entity Framework 6-applikation ställer innan de bestämmer sig för om migreringen är värd det. Microsoft publicerar benchmarks, men de liknar sällan frågorna i ett verkligt order- eller faktureringssystem.

Så vi skrev de frågor som ett sådant system innehåller och körde exakt samma frågor i tre uppsättningar: EF6 på .NET Framework 4.8, där de flesta EF6-applikationer fortfarande lever, EF6 på .NET 10, vilket går sedan EF 6.4, och EF Core 10 på .NET 10. Samma databas, samma data, samma entitetsklasser.

Det korta svaret: EF Core 10 var 1,6 till 17 gånger snabbare än EF6 på .NET Framework och använde upp till 28 gånger mindre minne. Den största skillnaden låg i att spara data, inte i att läsa den. Och EF6 på .NET 10 visade sig vara ett användbart mellansteg: snabbare än på .NET Framework, utan att du rör en enda fråga.

Så mätte vi

• Databasen: SQL Server (LocalDB) på samma maskin, med 1 000 kunder, 10 000 ordrar med ett anteckningsfält på 2 KB och 50 000 orderrader. En fjärdedel av ordrarna är öppna.
• Samma entitetsklasser i alla tre uppsättningarna, mappade mot samma tabeller. EF6 6.5.1 och EF Core 10.
• Verktyget: BenchmarkDotNet 0.15.8, med 3 uppvärmningsvarv och 12 uppmätta varv per fall, och minnesallokeringar registrerade.
• Varje fall öppnar en ny context, precis som ett webbanrop skulle göra. Inserts och uppdateringar körs i en transaktion som rullas tillbaka, så att varje varv ser samma data.
• Maskinen: en bärbar dator med Intel Core Ultra 7 255H.

De sju operationerna:

Operation	Vad den motsvarar
100 uppslag på id, ett i taget	Poster som laddas en och en i en skärmbild eller en import
Ladda 2 500 öppna ordrar, utan tracking	En lista eller rapport som bara läses
Ladda 2 500 öppna ordrar, med tracking	Samma lista, så som den mesta äldre koden laddar den
Projicera öppna ordrar till en liten klass	En listvy som är rätt byggd
Ladda 100 ordrar med deras rader (Include)	En orderdetalj eller en export
Lägga in 500 ordrar	En import eller ett batchjobb
Ladda och uppdatera 200 ordrar	En massändring av priser

Resultaten

Operation	EF6, .NET Framework 4.8	EF6, .NET 10	EF Core 10	EF Core 10 mot EF6 på 4.8
100 uppslag på id	30,2 ms	17,1 ms	8,0 ms	3,8× snabbare
2 500 ordrar, utan tracking	58,3 ms	44,0 ms	24,4 ms	2,4× snabbare
2 500 ordrar, med tracking	87,6 ms	59,3 ms	40,5 ms	2,2× snabbare
Projektion till en liten klass	9,0 ms	5,5 ms	5,8 ms	1,6× snabbare
100 ordrar med rader	17,4 ms	13,6 ms	11,1 ms	1,6× snabbare
Lägga in 500 ordrar	272,0 ms	127,7 ms	15,9 ms	17× snabbare
Uppdatera 200 ordrar	22,4 ms	18,7 ms	6,6 ms	3,4× snabbare

Minnet rörde sig åt samma håll, och i vissa fall betydligt längre:

Operation	EF6, .NET Framework 4.8	EF Core 10
100 uppslag på id	7,1 MB	1,6 MB
2 500 ordrar, utan tracking	31,2 MB	10,8 MB
2 500 ordrar, med tracking	37,3 MB	13,2 MB
Lägga in 500 ordrar	153,6 MB	5,4 MB
Uppdatera 200 ordrar	8,6 MB	2,5 MB

En ärlig anmärkning: insert-siffrorna för EF6 varierade mellan körningarna, från ungefär 250 till 330 ms på .NET Framework. Tabellen visar den sista körningen. Skillnaden mot EF Core var över 15 gånger i varje körning.

Att spara data: där skillnaden är störst

Inserten är den mest slående siffran, och den är värd att förstå, eftersom det också är där många EF6-applikationer förlorar mest tid i importer och nattliga jobb.

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

Samma kod i båda. Två saker gör EF6 långsamt här:

• EF6 skickar en INSERT per rad. 500 ordrar blir 500 separata kommandon till databasen. EF Core grupperar dem i ett fåtal batchade kommandon. På en riktig server över nätverket lägger var och en av de 500 rundturerna till latens, så skillnaden blir bara större.
• EF6 går igenom alla spårade entiteter vid varje Add. Varje anrop kör ändringsdetektering över allt som redan finns i contexten, så det blir långsammare att lägga till entiteter ju fler de är.

Det andra problemet har en billig lösning i EF6 självt, och den är värd att känna till även om du aldrig migrerar:

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

Med AddRange tog samma insert i EF6 80,9 ms i stället för 272 ms på .NET Framework och allokerade 21 MB i stället för 154 MB. Fortfarande fem gånger långsammare än EF Core, eftersom en insert per rad finns kvar, men en vinst på 3× för en ändrad rad kod. Om din EF6-applikation har en import som lägger till rader i en loop, börja där.

Uppdateringar följer samma mönster. EF Core skickar de 200 uppdateringarna i batcher och dess change tracker gör mindre arbete per entitet, vilket syns som 3,4 gånger högre hastighet och en tredjedel av minnet.

Att läsa data: stadiga vinster och en överraskning

För läsningar var EF Core 10 mellan 1,6 och 3,8 gånger snabbare. Den största vinsten fanns i många små frågor: 100 uppslag på id tog 30 ms i EF6 och 8 ms i EF Core. Varje fråga i EF Core har mycket mindre overhead när den översätts och körs, vilket spelar roll i kod som kör många små frågor, till exempel skärmbilder som laddar relaterad data en post i taget.

Överraskningen var projektionen. När frågan bara väljer de kolumner som skärmbilden behöver var EF6 på .NET 10 lika snabbt som EF Core 10: 5,5 ms mot 5,8 ms. Det mesta av arbetet sker där i databasen, och båda skickar en liknande SQL-fråga. Projektion är ett bra råd i alla versioner, vilket även vår artikel om de fem vanligaste EF Core-felen visade.

EF6 på .NET 10: ett användbart mellansteg

Många team ser migreringen som ett enda stort steg: från .NET Framework med EF6 till .NET 10 med EF Core. Det behöver den inte vara. EF6 har fungerat på modern .NET sedan version 6.4, och i våra mätningar blev det 1,2 till 2,1 gånger snabbare bara av att flyttas till .NET 10, utan att en enda fråga ändrades.

Det öppnar en väg i två steg:

1. Steg 1Flytta applikationen till .NET 10, behåll EF6
2. Steg 2Ersätt EF6 med EF Core, del för del

Det första steget ger dig en runtime med support och en del av hastigheten. Det andra kan sedan ske gradvis, med början i de delar som sparar mest data eller kör flest frågor. EF6 på modern .NET behöver sin konfiguration i kod i stället för i app.config, vilket tar några rader:

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

Det finns begränsningar: EF6-designern fungerar inte direkt i moderna .NET-projekt, så modeller som byggts från EDMX-filer kräver extra arbete, och EF6 är stabilt och har support men utvecklas inte längre aktivt. Det är en bro, inte ett slutmål. Hela flytten, och vad som gör den svårare eller lättare, beskriver vi i vår artikel om migrering från EF6 till EF Core.

Vad det betyder i praktiken

Några millisekunder per fråga låter lite. De blir mycket på de ställen där verksamheten faktiskt märker det:

• Importer och nattliga jobb. En import av 50 000 rader som lägger in i en loop är där 17× syns som timmar som blir minuter.
• Tungt använda skärmbilder. En skärmbild som kör 100 små frågor per laddning blir 22 ms snabbare per användare, varje gång, och servern gör en fjärdedel av allokeringsarbetet.
• Serverkostnader. Mindre minne per anrop betyder färre skräpinsamlingar och fler anrop per server, vilket spelar roll när du betalar för varje instans i Azure.

Och på ett sätt är siffrorna en nedre gräns: vår databas körde på samma maskin, så det fanns inget nätverk. På en riktig SQL Server eller Azure SQL kostar varje rundtur som EF6 gör och EF Core slipper dessutom nätverkslatens.

Hur mycket snabbare vanlig affärskod körs på .NET 10 än på .NET Framework, helt utan databas, visar vår mätning av .NET Framework 4.8 mot .NET 10.

Frågor vi ofta får

Är det värt att migrera från EF6 till EF Core bara för prestandans skull?

Oftast inte för prestandan enbart. Men prestanda är sällan det enda skälet: EF6 får inga nya funktioner, och det binder många applikationer till .NET Framework. Om du ändå flyttar till .NET 10 är EF Core där dataåtkomstlagret bör hamna. Börja med de delar som sparar mest data.

Kan vi helt enkelt köra EF6 på .NET 10?

Ja, sedan EF 6.4. Applikationer vars modell byggts i EF6-designern från en EDMX-fil kräver först lite extra arbete. I våra mätningar var det 1,2 till 2,1 gånger snabbare än på .NET Framework. Det är ett bra första steg, men inget långsiktigt hem.

Håller resultaten på en riktig SQL Server?

Riktningen gör det. De exakta millisekunderna beror på din server, din data och dina index. För inserts och uppdateringar blir skillnaden större över nätverket, eftersom EF6 gör många fler rundturer. Därför är det värt att mäta dina egna långsammaste operationer före och efter.

Vår EF6-import är långsam. Vad är den snabbaste vinsten?

Ersätt Add i en loop med ett enda AddRange, eller stäng av automatisk ändringsdetektering under importen. I vårt test gjorde bara det EF6-inserten tre gånger snabbare.

Så arbetar vi

Det här är precis vad vi gör. ProCoding är en .NET-studio i Split i Kroatien, och vi flyttar .NET Framework-applikationer och deras EF6-dataåtkomstlager till .NET 10 och EF Core: först mäter vi, sedan migrerar vi i steg som verksamheten inte märker, och varje steg kontrolleras med siffror. På egen hand, tillsammans med ditt team, eller med en .NET-konsult i ditt team. Första steget är kostnadsfritt. Boka ett kostnadsfritt samtal på 30 minuter.

Källor

• BenchmarkDotNet, mätverktyget vi använde
• Port from EF6 to EF Core, Microsoft Learn
• Compare EF Core and EF6, Microsoft Learn
• Efficient updating, Microsoft Learn
• Våra egna mätningar, oktober 2026, enligt beskrivningen ovan