C# IEnumerator/struttura di rendimento potenzialmente negativa?

Question

Contesto: ho un sacco di stringhe che sto ricevendo da un database e voglio restituirle. Tradizionalmente, sarebbe qualcosa di simile:

public List<string> GetStuff(string connectionString) 
{ 
    List<string> categoryList = new List<string>(); 
    using (SqlConnection sqlConnection = new SqlConnection(connectionString)) 
    { 
     string commandText = "GetStuff"; 
     using (SqlCommand sqlCommand = new SqlCommand(commandText, sqlConnection)) 
     { 
      sqlCommand.CommandType = CommandType.StoredProcedure; 

      sqlConnection.Open(); 
      SqlDataReader sqlDataReader = sqlCommand.ExecuteReader(); 
      while (sqlDataReader.Read()) 
      { 
       categoryList.Add(sqlDataReader["myImportantColumn"].ToString()); 
      } 
     } 
    } 
    return categoryList; 
} 

Ma poi ho capire il consumatore sta andando a voler scorrere gli elementi e non si preoccupa molto altro, e mi piacerebbe non me stesso in scatola ad una lista, di per sé, quindi se restituisco un IEnumerable tutto è buono/flessibile. Stavo pensando che potrei usare un "ritorno rendimento" tipo di progetto per gestire questa situazione ... qualcosa di simile:

public IEnumerable<string> GetStuff(string connectionString) 
{ 
    using (SqlConnection sqlConnection = new SqlConnection(connectionString)) 
    { 
     string commandText = "GetStuff"; 
     using (SqlCommand sqlCommand = new SqlCommand(commandText, sqlConnection)) 
     { 
      sqlCommand.CommandType = CommandType.StoredProcedure; 

      sqlConnection.Open(); 
      SqlDataReader sqlDataReader = sqlCommand.ExecuteReader(); 
      while (sqlDataReader.Read()) 
      { 
       yield return sqlDataReader["myImportantColumn"].ToString(); 
      } 
     } 
    } 
} 

Ma ora che sto leggendo un po 'di più su rendimento (su siti come questo .. .msdn non sembra menzionarlo), è apparentemente un pigro valutatore, che mantiene lo stato del populatore in giro, in previsione di qualcuno che chiede il valore successivo, e quindi lo esegue solo finché non restituisce il valore successivo.

Questo sembra buono nella maggior parte dei casi, ma con una chiamata DB, questo suona un po 'rischioso. Come un esempio un po 'forzato, se qualcuno chiede un IEnumerable da quello che sto compilando da una chiamata DB, ne riceve metà e poi si blocca in un loop ... per quanto posso vedere la mia connessione DB sta andando rimanere aperti per sempre.

Suona come chiedere guai in alcuni casi se l'iteratore non finisce ... mi manca qualcosa?

Answer 1

È un atto di bilanciamento: si desidera forzare immediatamente tutti i dati nella memoria in modo da poter liberare la connessione, o si desidera trarre vantaggio dallo streaming dei dati, al costo di legare la connessione per tutto ciò tempo?

Il modo in cui lo guardo, quella decisione dovrebbe potenzialmente essere all'altezza del chiamante, che sa di più su ciò che vogliono fare. Se si scrive il codice utilizzando un blocco iteratore, il chiamante può molto facilmente trasformato quella forma in streaming in una forma completamente tamponata:

List<string> stuff = new List<string>(GetStuff(connectionString)); 

Se, d'altra parte, si fa il buffer da soli, non c'è in modo che il chiamante possa tornare a un modello di streaming.

Quindi probabilmente utilizzerei il modello di streaming e dico esplicitamente nella documentazione che cosa fa e consiglio al chiamante di decidere in modo appropriato. Potresti anche voler fornire un metodo di supporto per chiamare fondamentalmente la versione in streaming e convertirla in un elenco.

Ovviamente, se non ti fidi dei tuoi chiamanti a prendere la decisione appropriata, e hai buone ragioni per credere che non vorranno mai veramente trasmettere i dati (ad esempio, non restituirà comunque molto) quindi andare per l'approccio elenco. In ogni caso, documentalo: potrebbe davvero influire sul modo in cui viene utilizzato il valore di ritorno.

Un'altra opzione per gestire grandi quantità di dati consiste nell'utilizzare i batch, ovviamente - questo sta pensando in qualche modo lontano dalla domanda originale, ma è un approccio diverso da considerare nella situazione in cui lo streaming sarebbe normalmente attraente.

Answer 2

Non ti manca nulla. Il tuo esempio mostra come NON usare il rendimento restituito. Aggiungere gli articoli a un elenco, chiudere la connessione e restituire l'elenco. La firma del metodo può ancora restituire IEnumerable.

Modifica: Detto questo, Jon ha un punto (così sorpreso!): Ci sono rare occasioni in cui lo streaming è in realtà la cosa migliore da fare dal punto di vista delle prestazioni. Dopo tutto, se si tratta di 100.000 (1.000.000? 10.000.000?) Righe di cui stiamo parlando qui, non si vuole caricare prima tutto in memoria.

Answer 3

No, siete sulla strada giusta ... la resa si blocca il lettore ... potete provarlo a fare un'altra chiamata database mentre chiamando il IEnumerable

Answer 4

Non rendimento uso qui. il tuo campione va bene.

Answer 5

Mi sono imbattuto in questo muro alcune volte. Le query del database SQL non sono facilmente eseguibili come i file. Invece, interrogare solo quanto si ritiene necessario e restituirlo come qualsiasi contenitore desiderato (IList<>, DataTable, ecc.). IEnumerable non ti aiuterà qui.

Answer 6

Quello che puoi fare è utilizzare un SqlDataAdapter e compilare un DataTable. Qualcosa di simile a questo:

public IEnumerable<string> GetStuff(string connectionString) 
{ 
    DataTable table = new DataTable(); 
    using (SqlConnection sqlConnection = new SqlConnection(connectionString)) 
    { 
     string commandText = "GetStuff"; 
     using (SqlCommand sqlCommand = new SqlCommand(commandText, sqlConnection)) 
     { 
      sqlCommand.CommandType = CommandType.StoredProcedure; 
      SqlDataAdapter dataAdapter = new SqlDataAdapter(sqlCommand); 
      dataAdapter.Fill(table); 
     } 

    } 
    foreach(DataRow row in table.Rows) 
    { 
     yield return row["myImportantColumn"].ToString(); 
    } 
} 

In questo modo, si sta interrogando tutto in un solo colpo, e chiudendo immediatamente la connessione, ma si sta ancora pigramente iterare il risultato. Inoltre, il chiamante di questo metodo non può trasmettere il risultato a un elenco e fare qualcosa che non dovrebbe fare.

Answer 7

Non sei sempre insicuro con IEnumerable. Se lasci il framework call GetEnumerator (che è quello che farà la maggior parte delle persone), allora sei al sicuro. In sostanza, sei sicuro come la professionalità e cura del codice utilizzando il metodo:

class Program 
{ 
    static void Main(string[] args) 
    { 
     // safe 
     var firstOnly = GetList().First(); 

     // safe 
     foreach (var item in GetList()) 
     { 
      if(item == "2") 
       break; 
     } 

     // safe 
     using (var enumerator = GetList().GetEnumerator()) 
     { 
      for (int i = 0; i < 2; i++) 
      { 
       enumerator.MoveNext(); 
      } 
     } 

     // unsafe 
     var enumerator2 = GetList().GetEnumerator(); 

     for (int i = 0; i < 2; i++) 
     { 
      enumerator2.MoveNext(); 
     } 
    } 

    static IEnumerable<string> GetList() 
    { 
     using (new Test()) 
     { 
      yield return "1"; 
      yield return "2"; 
      yield return "3"; 
     } 
    } 

} 

class Test : IDisposable 
{ 
    public void Dispose() 
    { 
     Console.WriteLine("dispose called"); 
    } 
} 

Sia che si può affort di lasciare la connessione al database aperto o non dipende dall'architettura pure. Se il chiamante partecipa a una transazione (e la connessione viene automaticamente inserita), la connessione verrà comunque mantenuta aperta dal framework.

Un altro vantaggio di yield è (quando si utilizza un cursore sul lato server), il codice non deve leggere tutti i dati (esempio: 1.000 elementi) dal database, se il consumatore desidera uscire dal ciclo in precedenza (esempio: dopo il decimo elemento). Questo può velocizzare i dati di query. Soprattutto in un ambiente Oracle, dove i cursori sul lato server sono il modo comune per recuperare i dati.

Answer 8

L'unico modo in cui ciò potrebbe causare problemi è se il chiamante abusa del protocollo di IEnumerable<T>. Il modo corretto per usarlo è chiamare Dispose su di esso quando non è più necessario.

L'implementazione generato dal yield return prende la chiamata Dispose come un segnale di eseguire qualsiasi finally blocchi aperti, che nel tuo esempio chiamerà Dispose sugli oggetti che hai creato nei using dichiarazioni.

Esistono numerose funzionalità linguistiche (in particolare foreach) che rendono molto semplice l'uso di IEnumerable<T> in modo corretto.

Answer 9

Per inciso - si noti che l'approccio IEnumerable<T> è essenzialmente ciò che i fornitori di LINQ (LINQ to SQL, LINQ to Entities) fanno per vivere. L'approccio ha vantaggi, come dice Jon. Tuttavia, ci sono anche problemi definiti - in particolare (per me) in termini di (la combinazione di) separazione | astrazione.

Quello che voglio dire è che:

• in uno scenario MVC (per esempio) si desidera che il "ottenere i dati" passo per realmente ottenere dati, in modo che è possibile verificare che funziona al Controller, non il vista (senza dover ricordare di chiamare .ToList() ecc)
• non è possibile garantire che un altro implementazione DAL sarà in grado per lo streaming di dati (ad esempio, una chiamata POX/WSE/sapone può siamo noi ually stream records); e non necessariamente vuole fare il comportamento confusamente differente (vale a dire il collegamento ancora aperta durante l'iterazione con una sola applicazione, e chiuso per un altro)

Questo si lega un po 'con i miei pensieri qui: Pragmatic LINQ.

Ma dovrei sottolineare - ci sono sicuramente momenti in cui lo streaming è altamente desiderabile. Non è una semplice cosa "sempre contro mai" ...

Answer 10

Si può sempre usare un thread separato per bufferizzare i dati (magari in coda) mentre si fa anche un yeild per restituire i dati. Quando l'utente richiede dati (restituiti tramite uno yeild), un oggetto viene rimosso dalla coda. I dati vengono aggiunti continuamente alla coda tramite il thread separato. In questo modo, se l'utente richiede i dati abbastanza velocemente, la coda non è mai piena e non ti devi preoccupare dei problemi di memoria. In caso contrario, la coda si riempirà, il che potrebbe non essere così grave. Se esiste una sorta di limitazione che si desidera imporre sulla memoria, è possibile imporre una dimensione massima della coda (a quel punto l'altro thread attenderà che gli elementi vengano rimossi prima di aggiungerne altri alla coda). Naturalmente, vorrai assicurarti di gestire le risorse (vale a dire la coda) correttamente tra i due thread.

In alternativa, è possibile forzare l'utente a passare in un valore booleano per indicare se i dati devono essere memorizzati o meno. Se true, i dati vengono memorizzati nel buffer e la connessione viene chiusa il prima possibile. Se false, i dati non vengono memorizzati nel buffer e la connessione al database rimane aperta finché l'utente ne ha bisogno. Avere un parametro booleano costringe l'utente a fare la scelta, il che garantisce di conoscere il problema.

Answer 11

modo leggermente più conciso per forzare la valutazione di iteratore:

using System.Linq; 

//... 

var stuff = GetStuff(connectionString).ToList();