Questo sito utilizza cookies solo per scopi di autenticazione sul sito e nient'altro. Nessuna informazione personale viene tracciata. Leggi l'informativa sui cookies.
Ciao, ho un problema con l'esportazione di dati da un dgv ad un pdf, utilizzando iText.
Praticamente una volta che parte l'esportazione, ovviamente più sono i dati contenuti della dgv e più tempo ci mette, e fin qui vabene, solo che oltre a più tempo, la memoria utilizzata dal processo del programma cresce a dismisura.
Con 5000 righe (circa) sfiora i 250MB di spazio.
Ho fatto la prova con 60000 righe e sono arrivato a 700MB .
Quindi più righe ci sono, più l'eccezione (incubo) OutOfMemory si avvicina.
Questo è un esempio di codice che utilizzo per passare i dati dalla dgv alla Table del documento pdf:
Codice sorgente - presumibilmente VB.NET
Dim tbh AsNew Table(dgv.ColumnCount)
Dim cel AsNew Cell
with tbh
For irow AsInteger= 0 To dgv.RowCount- 1
For icol AsInteger= 0 To dgv.ColumnCount- 1
cel =New Cell(dgv.Item(icol, irow).Value)
.addCell(cel)
next
next
endwith
Qualcuno ha qualche idea per evitare che la memoria utilizzata dal mio processo cresca così tanto da rischiare di generare un outofmemory?
Conta che crei un nuovo oggetto per ogni cella, quindi 60.000 * numero di colonne * memoria occupata da una cella: non è poco.
Conta che un oggetto tiene come minimo 6 bytes di memoria, e una stringa almeno 20 bytes (più 2 bytes per carattere). Supponendo che tu abbia solo cinque colonne, e che ogni cella contenga SOLO una stringa vuota (il che è impossibile, poiché conterrà molte altre proprietà e molti altri campi privati e una stringa non nulla), occuperai almeno 7.8 MB.
Conta che crei un nuovo oggetto per ogni cella, quindi 60.000 * numero di colonne * memoria occupata da una cella: non è poco.
Conta che un oggetto tiene come minimo 6 bytes di memoria, e una stringa almeno 20 bytes (più 2 bytes per carattere). Supponendo che tu abbia solo cinque colonne, e che ogni cella contenga SOLO una stringa vuota (il che è impossibile, poiché conterrà molte altre proprietà e molti altri campi privati e una stringa non nulla), occuperai almeno 7.8 MB.
Ho provato con uno stringbuilder, ma senza successo.
E non c'è nessun modo per risolvere questo problema?
Lo StringBuilder è notevolmente più veloce nella manipolazione, ma i dati memorizzati sono sempre gli stessi.
Per quanto mi sembra di capire dal tuo codice, non c'è niente che tu possa fare. Al massimo puoi provare a invocare GC.Collect() dopo ogni riga, ma usare i metodi del garbage collector è fortemente sconsigliato. Una soluzione intelligente, ma non compatibile col tuo caso, sarebbe quella di scrivere sequenzialmente i dati dalla grid al file: ossia prendi la cella (0,0), scrivi nel file il codice per disegnare quella cella, poi prendi la (0,1) e così via. Sarebbe comunque difficile anche senza una libreria, poiché i pdf contengono dati compressi a blocchi.
Lo StringBuilder è notevolmente più veloce nella manipolazione, ma i dati memorizzati sono sempre gli stessi.
Per quanto mi sembra di capire dal tuo codice, non c'è niente che tu possa fare. Al massimo puoi provare a invocare GC.Collect() dopo ogni riga, ma usare i metodi del garbage collector è fortemente sconsigliato. Una soluzione intelligente, ma non compatibile col tuo caso, sarebbe quella di scrivere sequenzialmente i dati dalla grid al file: ossia prendi la cella (0,0), scrivi nel file il codice per disegnare quella cella, poi prendi la (0,1) e così via. Sarebbe comunque difficile anche senza una libreria, poiché i pdf contengono dati compressi a blocchi.
Scusa l'ignoranza, perchè è sconsigliato usare metodi del garbage collector?
E' una forzatura: il processo di GC dovrebbe essere gestito solamente dal CLR e il programmatore non dovrebbe intervenire. In questo caso, Collect() diminuirebbe di molto le prestazioni del codice: inoltre, delle GC ripetute potrebbero erroneamente eliminare oggetti relativamente giovani a causa della rapida processione delle generazioni.
.
