Newsgroup: it.comp.lang.c++
Titolo: leggere grossi file

devo leggere un grosso file (100Mb) di dati e vorrei che fosse fatto il più
velocemente possibile. Il file è in ASCII, per esempio:
   58  1  e- 238.417 66.3559 0.401054 -128.257  -2.942 -3.72793 1.56435
254.504 107.161 -0.295054 -124.874       0       1
 0 -0.0414628 -0.0494366 -0.486032
è la prima riga. Io non voglio leggere tutte le entrate, adesso il ciclo è
così:
double energy, thetadeg ,costheta,phideg ,xp,yp,zp,energypri,thetaprideg ,
costhetapri, phidegpri, temp;
fin >> nEv >> id >> particle >> energy >> thetadeg >> costheta >> phideg >>
xp >> yp >> zp >> energypri >> thetaprideg >> costhetapri  >> phidegpri >>
temp >> temp>> temp >> temp >> temp >> temp;
quello che mi infastidisce è che per saltare le entrate che non mi servono
uso una variabile temp, che viene scritta di continuo, anche se non mi
serve.

 xp >> yp >> zp >> energypri >> thetaprideg >> costhetapri  >> phidegpri;
fin.ignore( std::numeric_limits<int>::max(), '\n' );
Leggermente piu' veloce.
Saluti.

 velocemente possibile. Il file è in ASCII, per esempio:
Non puoi leggerlo a blocchi?

 bit di precisione) ?
Portabilità dei dati, immagino. IMHO, dei dati numerici salvati in 
formato ascii verranno letti dal 99,99% dei programmi in circolazione, 
lo stesso non si può dire per un formato binario. Magari ogni 
laboratorio o dipartimento universitario ha i suoi programmi, scritti 
magari da tesisti o ricercatori e non da programmatori, alla fine 
salvare i dati in ascii è la cosa più quick, easy & safe che si possa 
fare. Io nella mia tesi ho fatto la stessa cosa, files di dati da 50M 
che comunque venivano importati senza problemi da Matlab.
Ciao
  Andrea

 stilistica ammassata in 100 MB 
...
l'output non è modificabile, è l'output di un monte carlo fatto da terzi.
Per sintetizzare l'output è del tipo:
numero evento, tipo particella, energia, ...
tutti i record sono della stessa struttura
1 e- 3.40
2 e- 4.50
3 e- 5.60
...
le colonne sono sempre separate con uno spazio e le righe con un \n. I
double sono solo con qualche decimale. Il problema è che per esempio io
vorrei leggere solo la terza colonna
double temp, energia;
string particella
fin >> temp >> particella >> energia;
e per fare questo devo leggere le prime due sprecando un sacco di tempo.

 e per fare questo devo leggere le prime due sprecando un sacco di tempo.
lo so, perché non è solo una lettura "raw", ma un vero parsing 
stringa e interpretazione dati (tipo trova la virgola, tieni 
conto di esponente etc etc), che una funzione di input numerico 
generale capace di interpretare qualunque formato testuale di 
numero, deve poter fare senza essere ottimizzata su nessuno in 
particolare.
Cmq prima di dire altro, chiariamo il problema della lunghezza 
record (riga).
ciao
Soviet

   Andrea

 pensi, tra l'altro ?).
non l'ho ancora provata, ma è l'unica cosa da fare

 non l'ho ancora provata, ma è l'unica cosa da fare
fin.read(struttura);
questa dovresti farla solo dopo avere convertito il file a 
record fissi, se usi la struttura statica sul genere che ho detto.
Se invece immetti una stringa di lunghezza dinamica, variabile, 
risparmi si qualcosa in termini di decodifica, ma ancora tocca a 
usare una bufferizzazione e leggere carattere per carattere 
(nella logica nascosta di read) sino a trovare il newline di 
fine riga. Anche in questo caso l'efficienza non raggiunge 
quella dell'input binario puro, con dimensione fissa 
predeterminata. Dato l'output profondamente regolare e 
prevedibile, direi che questo approccio si può sicuramente fare.
ciao
Soviet_Mario

 caso non lo era.
Quello che dici è sacrosanto, e quando a scrivere il codice è gente 
esperta di programmazione probabilmente va come dici tu; però la realtà 
è spesso diversa, come nel mio caso nella tesi, e allora la scelta più 
naturale è quella di salvare tutto in ascii; se poi hai problemi di 
spazio puoi zippare i dati (dopo averci lavorato sopra); se poi vengono 
anche problemi di prestazioni allora si inizia a pensare a salvare i 
dati in formato binario, ma solo se si presentano problemi... nel mio 
caso mi pare che matlab (o, per essere precisi, octave) impiegasse 
qualche secondo a caricare un set di dati in memoria e quattro o cinque 
minuti per elaborarli, non mi è passato nemmeno per l'anticamera del 
cervello di salvare i dati in formato binario; e neanche gli altri che 
erano con me in laboratorio si sono posti il problema ;-)
Ciao
  Andrea

   Andrea