[C#] Prestazioni funzioni

[rizzotti91]

Ciao, sto cercando di ottimizzare le prestazioni di un mio progetto ed ho un dubbio.
Ho una classe che svolge determinate operazioni ricorrenti nella mia applicazione, come per esempio caricare una DataTable in base ad una query:

 public static DataTable CaricaDt(string query, DataTable dt)
        {
                try
                {
                    Connection.Apri();
                    MySqlDataAdapter da = new MySqlDataAdapter(query, Connection.cnMySql);
                    da.Fill(dt);
                    Connection.Chiudi();
                    return dt;

Praticamente io dalla classe in cui necessito di questa datatable "riempita", mando come parametri la query e la datatable, la funzione riempie questa data table e poi la restituisce.

Il fatto che io invii come parametro una dataTable, la quale viene riempita e poi restituita, non equivale al copiare la datatable quando la invio come parametro e poi afarla nuovamente ricopiare quando scrivo:
datagrid.DataSource=CaricaDt(query,table)?
Se non sbaglio, non passando il riferimento della dataTable, io vado ogni volta a farla ricreare in ram o sbaglio?

[wingman87]

Sbagli perché dt, anche se non è passato "per riferimento", è un riferimento ad un oggetto datatable, in pratica è un indirizzo. Quindi quello che passi e quello che viene restituito è solo un indirizzo.

Vedi qui:
http://msdn.microsoft.com/it-it/libr...=vs.80%29.aspx

[gugoXX]

HA ragione wingman.
E infatti nel tuo esempio e' anche inutile restituire la DataTable
E' sufficiente non restituire nulla (void), in quanto il chiamante sa gia' che verra' modificata la stessa datatable passata alla funzione.

[rizzotti91]

Originariamente inviato da gugoXX

HA ragione wingman.
E infatti nel tuo esempio e' anche inutile restituire la DataTable
E' sufficiente non restituire nulla (void), in quanto il chiamante sa gia' che verra' modificata la stessa datatable passata alla funzione.

Siccome la uso così:

dataGrid.DataSource = Database.CaricaDt(query, table);

Se tolgo il ritorno e metto void, mi dice "Impossibile convertire implicitamente il tipo void in object"..

[[Kendall]]

Originariamente inviato da rizzotti91

Siccome la uso così:

dataGrid.DataSource = Database.CaricaDt(query, table);

Se tolgo il ritorno e metto void, mi dice "Impossibile convertire implicitamente il tipo void in object"..

Database.CaricaDt(query, dataGrid.DataSource);

[rizzotti91]

Due domande:
- Per utilizzarla come dici tu, il metodo che variazioni dovrebbe subire? Perché così vuole come parametro una datatable;
- Ci sarebbero vantaggi prestazionali?

[[Kendall]]

Originariamente inviato da rizzotti91

Due domande:
- Per utilizzarla come dici tu, il metodo che variazioni dovrebbe subire? Perché così vuole come parametro una datatable;
- Ci sarebbero vantaggi prestazionali?

Chiaramente era solo una traccia, e il metodo avrebbe bisogno di alcune modifiche.
Dal canto mio farei comunque in maniera differente e mi affiderei alle tecniche di binding. Ne hai mai avuto a che fare?

[rizzotti91]

Originariamente inviato da [Kendall]

Chiaramente era solo una traccia, e il metodo avrebbe bisogno di alcune modifiche.
Dal canto mio farei comunque in maniera differente e mi affiderei alle tecniche di binding. Ne hai mai avuto a che fare?

Si, ma non le utilizzo in quanto programmo tutto manualmente ed effettuo anche tutte le query di inserimento e modifiche manualmente, la datagrid mi serve solo per visualizzare..

[gugoXX]

Originariamente inviato da rizzotti91

Due domande:
- Per utilizzarla come dici tu, il metodo che variazioni dovrebbe subire? Perché così vuole come parametro una datatable;
- Ci sarebbero vantaggi prestazionali?

Database.CaricaDt(query, table);
dataGrid.DataSource = table;

Cambiando il parametro di ritorno della funzione in void, e null'altro.

[rizzotti91]

Originariamente inviato da gugoXX

Database.CaricaDt(query, table);
dataGrid.DataSource = table;

Cambiando il parametro di ritorno della funzione in void, e null'altro.

Differenze prestazionali?

Inviato dal mio GT-I9300 con Tapatalk 2

[[Kendall]]

Originariamente inviato da rizzotti91

Differenze prestazionali?

Inviato dal mio GT-I9300 con Tapatalk 2

Nessuna, ma ci guadagni in pulizia e chiarezza del codice.

La funzione che hai scritto è lineare e non ha alcun punto critico in quanto essenzialmente è una serie di chiamate a librerie della .NET.
Le criticità pertanto possono esserci piuttosto nel codice scritto in tali librerie (cosa che sinceramente dubito essendo strarevisionate).

[rizzotti91]

Ok grazie per il chiarimento.
Quindi ricapitolando, se ho capito bene, ogni qualvolta chiamo un metodo che lavora su una DataTable (o un oggetto .NET in generale? ), anche se tale metodo è in un'altra classe è come se stessi lavorando all'interno della classe in cui mi trovo a livello prestazionale? Non vado a perdere assolutamente nulla?

[nico159]

Originariamente inviato da rizzotti91

Ok grazie per il chiarimento.
Quindi ricapitolando, se ho capito bene, ogni qualvolta chiamo un metodo che lavora su una DataTable (o un oggetto .NET in generale? ), anche se tale metodo è in un'altra classe è come se stessi lavorando all'interno della classe in cui mi trovo a livello prestazionale? Non vado a perdere assolutamente nulla?

Gli unici dati che vengono copiati se passati come argomento sono i dati primitivi (stranne String) e le struct

Per tutto il resto sì, vengono passati solo riferimenti

[rizzotti91]

Altra piccola domanda: quando devo fare 3 query in base ad un valore inserito dall'utente per ricavare il valore di 3 campi di quel determinato record, inizialmente eseguivo le tre query singolarmente con ExecuteScalar ed avevo un valore alla volta, quindi un totale di 3 query.
Adesso stavo attuando il metodo di query unica, limitare il risultato ad una riga e mettere questa riga in una DataTable in modo che abbia tutti e tre i valori in un unico oggetto.
Di funzionare funziona ma mi chiedevo se sotto qualche punto di vista l'utilizzo di una DataTable per una sola riga potesse essere uno spreco e se fosse preferibile utilizzare altro o va bene così