[C#] WinForm vs WPF : winform piu veloce?

[pano1974]

Ciao a tutti.

Premetto che wpf non lo conosco molto.

Ho fatto lo stesso programma in winform ed in wpf ed ho constatato a mia sorpresa che winform è estremamente piu veloce .

Il programma fa questo:
prendo un file txt con circa 25000 righe in cui sono stati riportati dei dati in una determinata sequenza e devo creare un nuovo file txt con gli stessi dati ma ragruppati in maniera diversa.

LA versione in winform ci impiega qualche secondo la versione wpf quasi un minuto.

Il file viene letto una riga alla volta.

L'algoritmo è il medesimo per entrambi i programmi allora che cosa influisce sulla velocità di wpf?

Con un file da 50000 righe winform non ha nessun problema mentre wpf mi da un messaggio in cui si spiega che l'operazione in esecuzione dura piu di 60 secondi ecc...

qualche consiglio e/o spiegazione?

grazie in anticipo

[MarcoGG]

Ho fatto lo stesso programma in winform ed in wpf ed ho constatato a mia sorpresa che winform è estremamente piu veloce .


Contrariamente a quanto molti pensano, WPF NON è il "successore" nè "l'evoluzione" di Windows Forms.

Windows Forms è vivo e vegeto e così sarà per molto tempo ancora.
L'unica vera ragione per cui è necessario WPF sono le applicazioni particolarmente basate sull'interazione di elementi visivi e grafici di svariati tipi di media : animazioni Flash, 3D, incorporamento di documenti, ecc.

Tutto ciò, come è logico aspettarsi, costa in termini di prestazioni.

Per quanto vedo io, molti utenti si buttano a pesce in WPF, pensando erroneamente che sia "meglio" di Windows Forms, e spesso per eseguire task per cui andrebbe benissimo un'Application Console...


Il programma fa questo:
prendo un file txt con circa 25000 righe in cui sono stati riportati dei dati in una determinata sequenza e devo creare un nuovo file txt con gli stessi dati ma ragruppati in maniera diversa.

LA versione in winform ci impiega qualche secondo la versione wpf quasi un minuto.

Il file viene letto una riga alla volta.

L'algoritmo è il medesimo per entrambi i programmi allora che cosa influisce sulla velocità di wpf?

Con un file da 50000 righe winform non ha nessun problema mentre wpf mi da un messaggio in cui si spiega che l'operazione in esecuzione dura piu di 60 secondi ecc...


Sinceramente la differenza dei tempi di escuzione che riporti mi sembra eccessiva. Sicuro di leggere quel file in modo appropriato ?
WPF sarà mediamente più lento ma non credo fino a questo punto...

Comunque sia, in Windows Forms, il processo è semplice.
Se ogni riga di quel file rappresenta una "entità" con uno o più "attributi", dovrai creare Oggetti in memoria che mappano tali entità. Una volta ottenuta una List() di tali Oggetti, la potrai ri-ordinare e raggruppare in sotto-Liste a piacere, sfruttando anche gli utilissimi Metodi LINQ.
A quel punto scriverai il tuo file di output...
;)

A mio avviso, prestazioni a parte, per questo e una moltitudine di altri processi, non c'è alcun bisogno di WPF.

[pano1974]

concordo con tutto quello che hai detto a parte il fatto che una gestione di stringhe, anche se molte, non dovrebbe inficiare le prestazioni in wpf.

l'algoritmo è lo stesso e stesse sono le istruzioni sulle stringhe,lunica differenza è che in wpf ho usato un aprocio mvvm per collegare i risultati ai vari richtextbox o textbox usati...mah...soliti misteri di microsoft.

cmq a mio giudizio certe piccolissime applicazioni che costruisci in 10 minuti con winform in wpf ti aumenta il tempo di sviluppo o codice in modo esponenziale.

[[Kendall]]

Mhhh... Mi sembra molto strano comunque. Una cosa è parlare di prestazioni a livello video (quindi pesantezza e reattività dell'interfaccia), un'altra è parlare di algoritmi di lettura/scrittura su file che nulla hanno a che vedere con la parte grafica e il tutto avviene "dietro le quinte". Se magari posti qualche listato possiamo darti qualche dritta migliore, perchè ora come ora... boh, ripeto mi sembra molto strano.

[MarcoGG]

;38114007']Mhhh... Mi sembra molto strano comunque. Una cosa è parlare di prestazioni a livello video (quindi pesantezza e reattività dell'interfaccia), un'altra è parlare di algoritmi di lettura/scrittura su file che nulla hanno a che vedere con la parte grafica e il tutto avviene "dietro le quinte". Se magari posti qualche listato possiamo darti qualche dritta migliore, perchè ora come ora... boh, ripeto mi sembra molto strano.

Già, concordo.
Anch'io ho espresso il sospetto, soprattutto adesso che l'OP ha messo lì questa frase :
"in wpf ho usato un aprocio mvvm per collegare i risultati ai vari richtextbox o textbox usati"

"collegare i risultati ai vari richtextbox o textbox usati" è molto probabilmente alla base dei problemi di lentezza riscontrati.

[pano1974]

Già, concordo.
Anch'io ho espresso il sospetto, soprattutto adesso che l'OP ha messo lì questa frase :
"in wpf ho usato un aprocio mvvm per collegare i risultati ai vari richtextbox o textbox usati"

"collegare i risultati ai vari richtextbox o textbox usati" è molto probabilmente alla base dei problemi di lentezza riscontrati.

anch'io pensavo fosse un problema di refresh dei textbox di verifica ma a questi vengono collegati i risultati solo alla fine delle varie operazioni ulle stringhe.

cmq l'algoritmo usato (moolto bruteforce) è il seguente:

public void CaricaFile()
{
string data_appoggio = "";
string nuova_riga = "";
string nuovo_testo = "";
string str;
string descrizioni = "";
string descrizioni_appoggio = "";
string um = "data ";
string um_appoggio = "data ";
int count = 0;
Campione camp = new Campione();
clsOrigine o = new clsOrigine();

string fileOriginale;
Microsoft.Win32.OpenFileDialog dialog = new Microsoft.Win32.OpenFileDialog();
dialog.ShowDialog();
fileOriginale = dialog.FileName;

if (fileOriginale != "")
{
string testo = "";
int cont = 0;

System.IO.StreamReader file = new System.IO.StreamReader(@fileOriginale);
while ((str = file.ReadLine()) != null)
{
testo += str + "\n";
camp.riga = str;
NumRigheTesto = count++;
if (str == "\n" || str == "")
{
data_appoggio = "";
if (nuova_riga != "")
{
descrizioni = descrizioni_appoggio + "\n";
um = um_appoggio + "\n";
nuovo_testo += nuova_riga + "\n";
descrizioni_appoggio = "";
um_appoggio = "data ";
cont++;
}
}
else
{
camp.riga = str;
if (data_appoggio == "")
{
data_appoggio = camp.Data;
nuova_riga = data_appoggio;
}
descrizioni_appoggio += " | " + camp.Descrizione;
um_appoggio += " | " + camp.UM;
nuova_riga += " | " + camp.Valore;
}



}
file.Close();



this.NumRigheTestoModificato = cont;
o.TestoModificato = descrizioni + um + nuovo_testo;
o.Testo = testo;
Origine = o;
}
}

[RaouL_BennetH]

Hai provato ad utilizzare uno StringBuilder per costruire le tue stringhe ?

[pano1974]

Hai provato ad utilizzare uno StringBuilder per costruire le tue stringhe ?

ci avevo pensato (appena ho 2 minuti ci provo) ma la domanda rimane sempre la stessa:

stesso file,stesso algoritmo, winform vince nettamente in velocità!!!

ho provato anche a spostare l'algoritmo dal modelview al model ma nisba...stesso risultato.

[MarcoGG]

anch'io pensavo fosse un problema di refresh dei textbox di verifica ma a questi vengono collegati i risultati solo alla fine delle varie operazioni ulle stringhe.

cmq l'algoritmo usato (moolto bruteforce) è il seguente:
...


Questo dipende.
Tu esegui una lettura del file riga-per-riga.
Questi "refresh" sulla UI vengono ripetuti per ogni riga letta ?

Io ho solo dato uno sguardo superficiale al tuo codice, e vado parzialmente OT, grafica a parte, per concentrare l'attenzione solo sulla lettura, perchè ho come la sensazione che, rispetto a quanto avevi dichiarato di dover fare in apertura, ci sia troppo codice.

Il tuo scopo iniziale dichiarato è :
"Il programma fa questo:
prendo un file txt con circa 25000 righe in cui sono stati riportati dei dati in una determinata sequenza e devo creare un nuovo file txt con gli stessi dati ma ragruppati in maniera diversa."

Quello che non è chiaro è lo scopo di refreshare controlli UI in un processo che, spiegato così, può ( e deve ) essere esseguito senza coinvolgere controlli di sorta.

Se riesci a fare un esempio concreto e preciso di come è il file di testo in input e di come deve essere quello in output, ti si può rispondere in modo più specifico.

Hai provato ad utilizzare uno StringBuilder per costruire le tue stringhe ?

Quoto. E' sempre un'ottima alternativa al creare/concatenare in continuazione nuovi Oggetti String in memoria, soprattutto nelle operazioni cicliche che cinvolgono decine di migliaia di stringhe o più. :)

[tacchinox]

Non è che hai qualche INotifyPropertyChanged nelle properties ?
Perche' se tiri 25.000 eventi nel thread della UI per avere 25.000 refresh di textboxes, non mi stupirei che fosse lento.
Se proprio metti l'algoritmo in un altro thread.

[pano1974]

Questo è parte del file originale:


30/08/12 15:18:00 , Portata_in_uscita , 67,4 , m3/h
30/08/12 15:18:00 , Ammoniaca_in_ingresso , 8,5 , mg/l
30/08/12 15:18:00 , Solidi_sospesi_in_ingresso , 1250,7 , mg/l
30/08/12 15:18:00 , Solidi_sospesi_ispessitore , 0,0 , kg/m3
30/08/12 15:18:00 , Portata_fango_da_disidratare , -2,5 , n/a
30/08/12 15:18:00 , Ossingeno_linea_1 , 0,2 , mg/l
30/08/12 15:18:00 , Ammoniaca_linea_1 , 2,6 , mg/l
30/08/12 15:18:00 , Solidi_sospesi_linea_1 , 3,9 , kg/m3
30/08/12 15:18:00 , Assorbimento_soffiante_1_linea_1 , 25,3 , A
30/08/12 15:18:00 , Assorbimento_soffiante_2_linea_1 , 0,0 , A
30/08/12 15:18:00 , Solidi_sospesi_ricircolo_linea_1 , 7,6 , kg/m3
30/08/12 15:18:00 , Portata_supero_linea_1 , 0,0 , m3/h
30/08/12 15:18:00 , Ossigeno_linea_2 , 0,7 , mg/l
30/08/12 15:18:00 , Ammoniaca_linea_2 , 1,6 , mg/l
30/08/12 15:18:00 , Solidi_sospesi_linea_2 , 5,2 , kg/m3
30/08/12 15:18:00 , Assorbimento_soffiante_1_linea_2 , 0,0 , A
30/08/12 15:18:00 , Assorbimento_soffiante_2_linea_2 , 21,6 , A
30/08/12 15:18:00 , Solidi_sospesi_ricircolo_linea_2 , 4,59 , kg/m3
30/08/12 15:18:00 , Portata_supero_linea_2 , -0,1 , m3/h

30/08/12 15:19:06 , Portata_in_uscita , 65,59 , m3/h
30/08/12 15:19:06 , Ammoniaca_in_ingresso , 8,6 , mg/l
30/08/12 15:19:06 , Solidi_sospesi_in_ingresso , 1210,59 , mg/l
30/08/12 15:19:06 , Solidi_sospesi_ispessitore , 0,0 , kg/m3
30/08/12 15:19:06 , Portata_fango_da_disidratare , -2,5 , n/a
30/08/12 15:19:06 , Ossingeno_linea_1 , 0,2 , mg/l
30/08/12 15:19:06 , Ammoniaca_linea_1 , 2,7 , mg/l
30/08/12 15:19:06 , Solidi_sospesi_linea_1 , 3,9 , kg/m3
30/08/12 15:19:06 , Assorbimento_soffiante_1_linea_1 , 25,2 , A
30/08/12 15:19:06 , Assorbimento_soffiante_2_linea_1 , 0,0 , A
30/08/12 15:19:06 , Solidi_sospesi_ricircolo_linea_1 , 7,6 , kg/m3
30/08/12 15:19:06 , Portata_supero_linea_1 , 0,0 , m3/h
30/08/12 15:19:06 , Ossigeno_linea_2 , 0,7 , mg/l
30/08/12 15:19:06 , Ammoniaca_linea_2 , 1,6 , mg/l
30/08/12 15:19:06 , Solidi_sospesi_linea_2 , 5,09 , kg/m3
30/08/12 15:19:06 , Assorbimento_soffiante_1_linea_2 , 0,0 , A
30/08/12 15:19:06 , Assorbimento_soffiante_2_linea_2 , 21,6 , A
30/08/12 15:19:06 , Solidi_sospesi_ricircolo_linea_2 , 4,59 , kg/m3
30/08/12 15:19:06 , Portata_supero_linea_2 , -0,1 , m3/h

30/08/12 15:19:06 , Portata_in_uscita , 65,59 , m3/h
30/08/12 15:19:06 , Ammoniaca_in_ingresso , 8,6 , mg/l
30/08/12 15:19:06 , Solidi_sospesi_in_ingresso , 1210,59 , mg/l
30/08/12 15:19:06 , Solidi_sospesi_ispessitore , 0,0 , kg/m3
30/08/12 15:19:06 , Portata_fango_da_disidratare , -2,5 , n/a
30/08/12 15:19:06 , Ossingeno_linea_1 , 0,2 , mg/l
30/08/12 15:19:06 , Ammoniaca_linea_1 , 2,7 , mg/l
30/08/12 15:19:06 , Solidi_sospesi_linea_1 , 3,9 , kg/m3
30/08/12 15:19:06 , Assorbimento_soffiante_1_linea_1 , 25,2 , A
30/08/12 15:19:06 , Assorbimento_soffiante_2_linea_1 , 0,0 , A
30/08/12 15:19:06 , Solidi_sospesi_ricircolo_linea_1 , 7,6 , kg/m3
30/08/12 15:19:06 , Portata_supero_linea_1 , 0,0 , m3/h
30/08/12 15:19:06 , Ossigeno_linea_2 , 0,7 , mg/l
30/08/12 15:19:06 , Ammoniaca_linea_2 , 1,6 , mg/l
30/08/12 15:19:06 , Solidi_sospesi_linea_2 , 5,09 , kg/m3
30/08/12 15:19:06 , Assorbimento_soffiante_1_linea_2 , 0,0 , A
30/08/12 15:19:06 , Assorbimento_soffiante_2_linea_2 , 21,6 , A
30/08/12 15:19:06 , Solidi_sospesi_ricircolo_linea_2 , 4,59 , kg/m3
30/08/12 15:19:06 , Portata_supero_linea_2 , -0,1 , m3/h

30/08/12 15:20:07 , Portata_in_uscita , 68,9 , m3/h
30/08/12 15:20:07 , Ammoniaca_in_ingresso , 8,5 , mg/l
30/08/12 15:20:07 , Solidi_sospesi_in_ingresso , 1213,8 , mg/l
30/08/12 15:20:07 , Solidi_sospesi_ispessitore , 0,0 , kg/m3
30/08/12 15:20:07 , Portata_fango_da_disidratare , -2,5 , n/a
30/08/12 15:20:07 , Ossingeno_linea_1 , 0,2 , mg/l
30/08/12 15:20:07 , Ammoniaca_linea_1 , 2,7 , mg/l
30/08/12 15:20:07 , Solidi_sospesi_linea_1 , 3,9 , kg/m3
30/08/12 15:20:07 , Assorbimento_soffiante_1_linea_1 , 25,2 , A
30/08/12 15:20:07 , Assorbimento_soffiante_2_linea_1 , 0,0 , A
30/08/12 15:20:07 , Solidi_sospesi_ricircolo_linea_1 , 7,6 , kg/m3
30/08/12 15:20:07 , Portata_supero_linea_1 , 0,0 , m3/h
30/08/12 15:20:07 , Ossigeno_linea_2 , 0,7 , mg/l
30/08/12 15:20:07 , Ammoniaca_linea_2 , 1,5 , mg/l
30/08/12 15:20:07 , Solidi_sospesi_linea_2 , 5,0 , kg/m3
30/08/12 15:20:07 , Assorbimento_soffiante_1_linea_2 , 0,0 , A
30/08/12 15:20:07 , Assorbimento_soffiante_2_linea_2 , 21,6 , A
30/08/12 15:20:07 , Solidi_sospesi_ricircolo_linea_2 , 4,59 , kg/m3
30/08/12 15:20:07 , Portata_supero_linea_2 , -0,1 , m3/h

30/08/12 15:20:07 , Portata_in_uscita , 68,9 , m3/h
30/08/12 15:20:07 , Ammoniaca_in_ingresso , 8,5 , mg/l
30/08/12 15:20:07 , Solidi_sospesi_in_ingresso , 1213,8 , mg/l
30/08/12 15:20:07 , Solidi_sospesi_ispessitore , 0,0 , kg/m3
30/08/12 15:20:07 , Portata_fango_da_disidratare , -2,5 , n/a
30/08/12 15:20:07 , Ossingeno_linea_1 , 0,2 , mg/l
30/08/12 15:20:07 , Ammoniaca_linea_1 , 2,7 , mg/l
30/08/12 15:20:07 , Solidi_sospesi_linea_1 , 3,9 , kg/m3
30/08/12 15:20:07 , Assorbimento_soffiante_1_linea_1 , 25,2 , A
30/08/12 15:20:07 , Assorbimento_soffiante_2_linea_1 , 0,0 , A
30/08/12 15:20:07 , Solidi_sospesi_ricircolo_linea_1 , 7,6 , kg/m3
30/08/12 15:20:07 , Portata_supero_linea_1 , 0,0 , m3/h
30/08/12 15:20:07 , Ossigeno_linea_2 , 0,7 , mg/l
30/08/12 15:20:07 , Ammoniaca_linea_2 , 1,5 , mg/l
30/08/12 15:20:07 , Solidi_sospesi_linea_2 , 5,0 , kg/m3
30/08/12 15:20:07 , Assorbimento_soffiante_1_linea_2 , 0,0 , A
30/08/12 15:20:07 , Assorbimento_soffiante_2_linea_2 , 21,6 , A
30/08/12 15:20:07 , Solidi_sospesi_ricircolo_linea_2 , 4,59 , kg/m3
30/08/12 15:20:07 , Portata_supero_linea_2 , -0,1 , m3/h

30/08/12 15:21:13 , Portata_in_uscita , 77,2 , m3/h
30/08/12 15:21:13 , Ammoniaca_in_ingresso , 8,69 , mg/l
30/08/12 15:21:13 , Solidi_sospesi_in_ingresso , 1224,09 , mg/l
30/08/12 15:21:13 , Solidi_sospesi_ispessitore , 0,0 , kg/m3
30/08/12 15:21:13 , Portata_fango_da_disidratare , -2,5 , n/a
30/08/12 15:21:13 , Ossingeno_linea_1 , 0,2 , mg/l
30/08/12 15:21:13 , Ammoniaca_linea_1 , 2,6 , mg/l
30/08/12 15:21:13 , Solidi_sospesi_linea_1 , 3,9 , kg/m3
30/08/12 15:21:13 , Assorbimento_soffiante_1_linea_1 , 25,2 , A
30/08/12 15:21:13 , Assorbimento_soffiante_2_linea_1 , 0,0 , A
30/08/12 15:21:13 , Solidi_sospesi_ricircolo_linea_1 , 7,6 , kg/m3
30/08/12 15:21:13 , Portata_supero_linea_1 , 0,0 , m3/h
30/08/12 15:21:13 , Ossigeno_linea_2 , 0,8 , mg/l
30/08/12 15:21:13 , Ammoniaca_linea_2 , 1,5 , mg/l
30/08/12 15:21:13 , Solidi_sospesi_linea_2 , 5,0 , kg/m3
30/08/12 15:21:13 , Assorbimento_soffiante_1_linea_2 , 0,0 , A
30/08/12 15:21:13 , Assorbimento_soffiante_2_linea_2 , 21,6 , A
30/08/12 15:21:13 , Solidi_sospesi_ricircolo_linea_2 , 4,7 , kg/m3
30/08/12 15:21:13 , Portata_supero_linea_2 , -0,1 , m3/h




mentre questo è il risultato:



| Portata_in_uscita | Ammoniaca_in_ingresso | Solidi_sospesi_in_ingresso | Solidi_sospesi_ispessitore | Portata_fango_da_disidratare | Ossingeno_linea_1 | Ammoniaca_linea_1 | Solidi_sospesi_linea_1 | Assorbimento_soffiante_1_linea_1 | Assorbimento_soffiante_2_linea_1 | Solidi_sospesi_ricircolo_linea_1 | Portata_supero_linea_1 | Ossigeno_linea_2 | Ammoniaca_linea_2 | Solidi_sospesi_linea_2 | Assorbimento_soffiante_1_linea_2 | Assorbimento_soffiante_2_linea_2 | Solidi_sospesi_ricircolo_linea_2 | Portata_supero_linea_2
data | m3/h | mg/l | mg/l | kg/m3 | n/a | mg/l | mg/l | kg/m3 | A | A | kg/m3 | m3/h | mg/l | mg/l | kg/m3 | A | A | kg/m3 | m3/h
30/08/12 15:18:00 | 67,4 | 8,5 | 1250,7 | 0,0 | -2,5 | 0,2 | 2,6 | 3,9 | 25,3 | 0,0 | 7,6 | 0,0 | 0,7 | 1,6 | 5,2 | 0,0 | 21,6 | 4,59 | -0,1
30/08/12 15:19:06 | 65,59 | 8,6 | 1210,59 | 0,0 | -2,5 | 0,2 | 2,7 | 3,9 | 25,2 | 0,0 | 7,6 | 0,0 | 0,7 | 1,6 | 5,09 | 0,0 | 21,6 | 4,59 | -0,1
30/08/12 15:19:06 | 65,59 | 8,6 | 1210,59 | 0,0 | -2,5 | 0,2 | 2,7 | 3,9 | 25,2 | 0,0 | 7,6 | 0,0 | 0,7 | 1,6 | 5,09 | 0,0 | 21,6 | 4,59 | -0,1
30/08/12 15:20:07 | 68,9 | 8,5 | 1213,8 | 0,0 | -2,5 | 0,2 | 2,7 | 3,9 | 25,2 | 0,0 | 7,6 | 0,0 | 0,7 | 1,5 | 5,0 | 0,0 | 21,6 | 4,59 | -0,1
30/08/12 15:20:07 | 68,9 | 8,5 | 1213,8 | 0,0 | -2,5 | 0,2 | 2,7 | 3,9 | 25,2 | 0,0 | 7,6 | 0,0 | 0,7 | 1,5 | 5,0 | 0,0 | 21,6 | 4,59 | -0,1



la visualizzazione del file di origine e del file modificato su due textbox avvengono solo dopo che sono state fatte tutte le elaborazioni dell'algoritmo, sia in winfoem che in wpf.

[Kralizek]

ad occhio stai facendo due errori:

1) mischi un po' troppo logica ed UI
2) sei sceso troppo a basso livello dimenticando LINQ ;)

Qui (http://pastebin.com/CyN04fC2) ho tirato giù due linee per vedere come si fa facile con LINQ :)

Se il file è molto grosso ma le colonne sono fisse, invece di buttare tutto in una DataTable, puoi usare un buffer in cui butti una riga per volta e che l'UI mette a video non appena trova (in questo caso l'utilizzo del framework RX è una manna)

[[Kendall]]

ad occhio stai facendo due errori:

1) mischi un po' troppo logica ed UI
2) sei sceso troppo a basso livello dimenticando LINQ ;)

Qui (http://pastebin.com/CyN04fC2) ho tirato giù due linee per vedere come si fa facile con LINQ :)

Se il file è molto grosso ma le colonne sono fisse, invece di buttare tutto in una DataTable, puoi usare un buffer in cui butti una riga per volta e che l'UI mette a video non appena trova (in questo caso l'utilizzo del framework RX è una manna)

Linq mi capita di utilizzarlo spesso, ma mai per query molto pesanti.
A livello di efficienza sai a che livello è rispetto a del codice home-made dedicato e ben scritto? (ovviamente sulla semplicità e rapidità di utilizzo del primo rispetto al secondo siamo su altri pianeti).

[pano1974]

potrei anche togliere la visualizzazione dei file, non è questo il risultato ma bensì il nuovo file di testo.

ribadisco che la visualizzazione avviene SOLO dopo l'elaborazione del file quindi penso che non sia un problema di visualizzazione in wpf (però potrei sbagliarmi visto le mie forti lacune in wpf).

Ora proverò a rifare il programma in wpf senza mvvm che non sia il pattern magari a rompere le scatole :)

[Kralizek]

;38133674']Linq mi capita di utilizzarlo spesso, ma mai per query molto pesanti.
A livello di efficienza sai a che livello è rispetto a del codice home-made dedicato e ben scritto? (ovviamente sulla semplicità e rapidità di utilizzo del primo rispetto al secondo siamo su altri pianeti).

diciamo che é possibile scrivere codice efficiente con LINQ (naturalmente stiamo parlando specificatamente del provider Linq 2 Objects), l'importante é sapere esattamente quali sono gli operatori che causano lo "svolgimento" dell'enumerazione e far sí che ció accada solo quando lo si vuole, perché lo si vuole.

Ad esempio nel codice di prima, c'é una grossa inefficienza dovuta all'uso dell'operatore Distinct() ma che puó essere rimossa a patto di scrivere a mano i nomi delle colonne (cosa che non avevo voglia ieri sera :Prrr: ).

Importante é tenere d'occhio operatori come OrderBy() e GroupBy() perché, fedeli alla filosofica funzionale, non modificano mai il dato originale creando nuove collection contenitrici.

Esistono esempi di codice di operatori riscritti in modo da aumentare le loro performance attraverso la modifica dell collection originale.

Infine, LINQ é il modo piú semplice di integrare dati eterogenei da sorgenti eterogenee senza escludere la possibilitá di passare al processo parallelo attraverso PLINQ ed alla programmazione reattiva attraverso RX.

TL;DR: si, chi scrive a mano un metodo puó essere piú efficiente, ma piuttosto io spenderei tempo a (ri)scrivere i singoli metodi di LINQ per poi riutilizzarli altrove.

[[Kendall]]

potrei anche togliere la visualizzazione dei file, non è questo il risultato ma bensì il nuovo file di testo.

ribadisco che la visualizzazione avviene SOLO dopo l'elaborazione del file quindi penso che non sia un problema di visualizzazione in wpf (però potrei sbagliarmi visto le mie forti lacune in wpf).

Ora proverò a rifare il programma in wpf senza mvvm che non sia il pattern magari a rompere le scatole :)

Secondo me una prova del 9 è prenderti quegli algoritmi, crearti sia in wpf che in windows form una schermata vuota con un semplice campo di testo al centro ed un pulsante per far partire la selezione e l'analisi del file. Alla fine del processo di lettura e computazione dei risultati stampi a schermo sul campo di testo un messaggio a tuo piacimento (non so, un "fatto", "OK", "Dai Cazzo!" o quel che ti pare :D ). Così la parte grafica è ridotta all'osso e anche di più e non metti in mezzo le librerie grafiche. In una situazione del genere non vedo come l'applicazione wpf possa essere più lenta di quella winform e puoi avere così la riprova

[[Kendall]]

diciamo che é possibile scrivere codice efficiente con LINQ (naturalmente stiamo parlando specificatamente del provider Linq 2 Objects), l'importante é sapere esattamente quali sono gli operatori che causano lo "svolgimento" dell'enumerazione e far sí che ció accada solo quando lo si vuole, perché lo si vuole.

Ad esempio nel codice di prima, c'é una grossa inefficienza dovuta all'uso dell'operatore Distinct() ma che puó essere rimossa a patto di scrivere a mano i nomi delle colonne (cosa che non avevo voglia ieri sera :Prrr: ).

Importante é tenere d'occhio operatori come OrderBy() e GroupBy() perché, fedeli alla filosofica funzionale, non modificano mai il dato originale creando nuove collection contenitrici.

Esistono esempi di codice di operatori riscritti in modo da aumentare le loro performance attraverso la modifica dell collection originale.

Infine, LINQ é il modo piú semplice di integrare dati eterogenei da sorgenti eterogenee senza escludere la possibilitá di passare al processo parallelo attraverso PLINQ ed alla programmazione reattiva attraverso RX.

TL;DR: si, chi scrive a mano un metodo puó essere piú efficiente, ma piuttosto io spenderei tempo a (ri)scrivere i singoli metodi di LINQ per poi riutilizzarli altrove.

Grazie mille della delucidazione... ;)

P.S: so che il discorso andrebbe circoscritto all'applicazione ma, in generale, da appassionato sia di c++ che di java (ma soprattutto del primo), beh, C# è il mondo dei balocchi. E' un piacere programmarvi ed infatti non uso altro da praticamente un anno e mezzo.

[RaouL_BennetH]

Vi chiedo scusa (in particolar modo all'autore del 3d) ... ma a proposito di velocità in merito a LinQ, potreste darmi una mano nel mio 3d (databinding->datagridview) ??

E' una cosa che non faccio mai ... ma mi si sta davvero attanagliando lo stomaco ....

[pano1974]

;38138850']Secondo me una prova del 9 è prenderti quegli algoritmi, crearti sia in wpf che in windows form una schermata vuota con un semplice campo di testo al centro ed un pulsante per far partire la selezione e l'analisi del file. Alla fine del processo di lettura e computazione dei risultati stampi a schermo sul campo di testo un messaggio a tuo piacimento (non so, un "fatto", "OK", "Dai Cazzo!" o quel che ti pare :D ). Così la parte grafica è ridotta all'osso e anche di più e non metti in mezzo le librerie grafiche. In una situazione del genere non vedo come l'applicazione wpf possa essere più lenta di quella winform e puoi avere così la riprova

volevo provare oggi a farlo.
Ho provato a rifare l'algoritmo usando stringbuilder invece di usare delle comuni string (già una volta in un programma simile avevo incrementato di vari ordini di grandezza la velocità)...ma anche così wpf è lentissimo, poi ora che il file da analizzare è diventato di circa 120000 riga.

P.S.
per chi consiglia linq vorrei aggiungere che i dati memorizzati nel datalogger (il file da trattare è generato da un datalogger) possono aumentare ma mai diminuire.

posterò oggi il codice di entrambe le versioni così potrete vedere che cosa succede, per il file da analizzare non so dove postarlo

[Kralizek]

volevo provare oggi a farlo.
Ho provato a rifare l'algoritmo usando stringbuilder invece di usare delle comuni string (già una volta in un programma simile avevo incrementato di vari ordini di grandezza la velocità)...ma anche così wpf è lentissimo, poi ora che il file da analizzare è diventato di circa 120000 riga.

P.S.
per chi consiglia linq vorrei aggiungere che i dati memorizzati nel datalogger (il file da trattare è generato da un datalogger) possono aumentare ma mai diminuire.

posterò oggi il codice di entrambe le versioni così potrete vedere che cosa succede, per il file da analizzare non so dove postarlo

dai un'occhiata ad RX. ( http://msdn.microsoft.com/en-us/data/gg577609.aspx )

non ho visto se é possibile leggere il file mentre qualcun altro ci scrive, ma prendere i dati non appena vengono scritti e processarli non sarebbe male :)

prendi quest'esempio ( http://stackoverflow.com/questions/11135968/how-to-read-interleaved-file-concurrently-using-reactive-extensions ) dove in pratica processa il dato non appena viene letto dal file :)