Iterazione su grandi raccolte in C#: impiega molto tempo

Question

Recentemente ho avviato un'applicazione WPF. L'ho collegato a un database BaseX (basato su XML) e recuperato circa un milione di voci da esso. Volevo iterare le voci, calcolare qualcosa per ogni voce e poi scrivere che nel database:

IEnumerable<Result> resultSet = baseXClient.Query("...", "database"); 
foreach (Result result in resultSet) 
{ 
    ... 
} 

Il problema: L'interno del foreach non viene mai raggiunto. il metodo Query() ritorna abbastanza veloce, ma quando viene raggiunto il foreach C# sembra fare SOMETHING con la collezione, il codice non continua per un tempo molto lungo (almeno 10 minuti, non lasciarlo mai più funzionare). Cosa sta succedendo qui? Ho provato a limitare il numero di elementi recuperati. Quando si recuperano 100.000 risultati, si verifica la stessa cosa ma il codice continua dopo circa 10-20 secondi. Quando recuperi l'intero milione di risultati, C# sembra essere bloccato per sempre ...

Qualche idea? saluti

Modifica: perché questo sta accadendo Come alcuni di voi hanno sottolineato, la ragione di questo comportamento sembra essere che la query è in realtà valutata solo quando MoveNext() sul Enumeratore all'interno del Enumerable si chiama. Il mio database sembra non essere in grado di restituire un valore alla volta, ma restituisce invece l'intero milione di set di dati contemporaneamente. Cercherò di passare ad un altro database (Apache Lucene, se possibile, dato che ha un buon supporto per la ricerca fulltext) e modificare questo post per farti sapere se ha cambiato qualcosa.
PS: Sì, sono consapevole che un milione di risultati è molto. Questo non è pensato per l'uso dal vivo, è solo un passo per la preparazione dei dati. Mentre non mi aspettavo che il codice potesse essere eseguito in pochi secondi, ero ancora sorpreso di vedere prestazioni scadenti nel database.

Modifica: la soluzione Così ho migrato il database XML ad Apache Lucine. Funziona come un fascino! Ovviamente Lucine è un database testuale che non è adatto per ogni caso d'uso, ma per me ha funzionato a meraviglia. Può iterare oltre un milione di voci in pochi secondi, viene recuperata una voce per ciclo - funziona molto bene!

Answer 1

Un milione di qualsiasi cosa è molto ... quindi qualsiasi operazione che ottiene molti elementi richiede un tempo considerevole. Sembra che la libreria che usi non differisca il recupero degli oggetti finché non sia assolutamente necessario, quindi vedi l'impatto di ottenere tutti gli oggetti nascosti dietro la frase "foreach".

Cosa accade:

"foreach" non è una singola operazione, ma piuttosto diverse chiamate su IEnumerable e IEnumerator: IEnumerable.GetEnumerator, chiamate a IEnumerator.MoveNext ripetute.

Prima chiamata GetEnumerator può essere implementato con esecuzione differita (modo più comune come query LINQ sono scritti) o esecuzione immediata (che sembra essere il caso della vostra collezione.

chiamate ai MoveNext potrebbero anche innescare l'esecuzione immediata di tutta la query anche se stai chiedendo solo per un singolo articolo o ogni chiamata può ottenere solo un singolo elemento.Perché la maggior parte delle query LINQ ottiene solo un elemento successivo dall'iteratore.

Answer 2

Hai provato un ciclo più tradizionale per vedere se avrebbe funzionato?

IEnumerable<Result> resultSet = baseXClient.Query("...", "database"); 
for (int x =0; x < resultSet.Count; x++) 
{ 
    Result result = resultSet[x]; 
    ... 
} 

Answer 3

Lasciami Quess - non sta caricando i dati quando youcreate il rsultSet, ma quando è primo accesso (esecuzione in ritardo), e il caricamento di un milione di voci si prende un sacco di tempo a loro deserializzare in memoria .

Benvenuti alle inefficienze dei database XML.

Answer 4

Per forzare la valutazione della query prima del foreach, chiamare la funzione ToList sul resultSet. (non risolverà il tuo problema se il problema è il database che dura per sempre)

Answer 5

Le risposte qui indicano tutte la causa del tuo problema percepito con foreach (esecuzione differita), ma non a una possibile soluzione. Non sono sicuro che questo database lo supporti, ma una soluzione potrebbe essere quella di provare il cercapersone ults in batch più piccoli, piuttosto che ottenere l'intera porzione di dati contemporaneamente.

Un'alternativa è scrivere una query di database che esegue i calcoli necessari, in modo che il database non debba inviare mai 1 milione di record ovunque. (Ancora una volta, non sono sicuro che questo database supporti questo)