Attualmente sto lavorando a un progetto in cui sostituirò il Data Access Layer da un ORM personalizzato a Entity Framework. (Il prodotto è quasi completo e per lo più tutte le modifiche che seguiranno dopo il suo completamento sarebbero richieste di modifica o bug correzioni).
La metrica assoluta più importante sarebbe il numero di query di database eseguite. Se la traduzione del codice logico da parte dell'ORM ha come conseguenza un numero diverso di query, questo avrà un effetto che farà apparire minuscola qualsiasi altra differenza. Dovresti stare particolarmente attento alla "n + 1" -pattern in cui l'ORM eseguirà una singola query per ogni oggetto di una collezione quando attraverserai sotto-oggetti. Almeno in EF hai spesso la scelta tra il caricamento desideroso e pigro (n + 1) di oggetti secondari, quindi assicurati di sapere come utilizzare l'ORM in modo ottimale prima di chiudere l'uno o l'altro.
In secondo luogo, dovresti esaminare la quantità di dati restituiti dal database. Ci potrebbe essere una differenza se un ORM esegue un filtro sul lato client e un altro lo fa in SQL. Alcuni ORMS sono più intelligenti di altri nel modo in cui traducono i filtri in sql. Ovviamente è preferibile filtrare il più possibile dal lato del database.
Se gli ORM invece generano sql equivalente (che non è improbabile), la differenza di prestazioni sarà probabilmente piccola, forse anche trascurabile, e dovresti basare la tua scelta su altri fattori come la manutenibilità e la familiarità degli sviluppatori.
Leggi altre domande sui tag design performance entity-framework orm