Ciao,
penso che il problema non sia nelle 1200 righe. Anche se è un buon numero, leggerle dal db e ciclarle con un foreach non dovrebbe richiedere così tanto tempo da destare preoccupazione (certo, se riesci a ridurne il numero è meglio).
Di solito, la lentezza dipende da query molto complesse ma tu hai detto che viene eseguita velocemente e che non è quello il problema. L'importante è che tu abbia misurato bene i tempi e che tu sia consapevole della deferred execution delle query LINQ.
https://blogs.msdn.microsoft.com/charlie/2007/12/10/linq-and-deferred-execution/Il cronometro va avviato subito prima di invocare il .ToList() e fermato subito dopo. Quello è il tempo effettivo che impiega la tua applicazione a recuperare i dati dal db.
A questo punto passi la lista all'algoritmo. Hai misurato anche il suo tempo di esecuzione? Come si rapporta al tempo di esecuzione della query?
Se scopri che il problema è nell'algoritmo, può darsi che dipenda dal fatto che stai accedendo alle proprietà di navigazione delle 1200 entità.
Cito proprio questa tra le tante cause possibili perché è forse quella più subdola: se hai il lazy loading abilitato (lo è per default), Entity Framework ti fornirà i dati dalle proprietà di navigazione ma questo lo costringe ad effettuare almeno una query per ciascuna delle 1200 entità. E' un problema conosciuto come SELECT n+1 e lo trovi spiegato qui.
http://blogs.microsoft.co.il/gilf/2010/08/18/select-n1-problem-how-to-decrease-your-orm-performance/Se è questo il problema, la soluzione consiste nell'aggiungere degli .Include alla tua query linq per chiedere ad EF di recuperare tutti i dati dalle entità correlate in un solo round-trip al database.
Per capire quale sia effettivamente il problema, servono altre informazioni. Usa la strumentazione di Visual Studio e/o la classe Stopwatch per misurare i tempi di esecuzione.
ciao,
Moreno
