Newsgroup: it.comp.java
Titolo: Parsing di stringhe float.

Ho realizzato un programma che legge da un file dei valori float in formato
testo ed incolonnati su 2 colonne per costruire una matrice nx2 di float.
Il problema e` che con file molto grandi (dell'orine dei 2 MBytes) il tempo
di conversione si allunga enormemente fino a 3 sec.
Ho scoperto, facendo diverse misure, che la perdita di tempo principale
deriva dalla costruzione della String da passare alla funzione
FLoat.parseFLoat(String str).
Ho costruito un oggetto che effettua la conversione partendo da un array di
caratteri ma le possibilita` sono limitate e le prestazioni, pur essendo 5
volte migliori, sono scarse rispetto alla funzione FLoat.parseFloat(String
str).
La variabile reference della Stringa passata era sempre visibile e quindi
non veniva deallocata ma nell'aggiungere i caratteri letti di volta in
volta (devo passare per un parser che toglie i valori spuri) tramite la
funzione += (o cat) vi era una gran perdita di tempo.
Qualcuno cono sce un modo per convertire da array di catarreri a float nel
modo piu` performante possibile?
razie 1000.

 modo piu` performante possibile?
IMHO la tua applicazione è già abbastanza performante col parseFloat. 
Alla Sun ci hanno lavorato parecchio, se si fosse potuto far di meglio 
probabilmente l'avrebbero fatto :)
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://www.sourceforge.net/projects/ammentos
http://ammentos.biobytes.it

 
IL problema non e` la latenza di lettura da disco perche` questa viene
eseguita in un thread separato ed i dati vengono posti in un buffer
preallocato della stessa dimensione del file per poi essere prelevati dal
thread che effettua il parsing il quale legge fino all'ultimo byte scritto
esegue la yield() e riparte dal byte successivo ciclicamente fino a che non
si arriva alla fine bel buffer.
Dalle mie misure risulta che la perdita di tempo non e` nel
Float.parseFloat() (come ho gia` scritto precedentemente!) ma
nell'inserimento dei byte letti nella stringa da passare a tale funzione.

 nell'inserimento dei byte letti nella stringa da passare a tale funzione.
Ma... non è che stai utilizzando un inputstream invece di un 
(Buffered)Reader per leggere il file di testo?


 funzione += (o cat) vi era una gran perdita di tempo.
Cioe' ogni volta aumentavi la grandezza della stringa ? Questo e' male, 
dato che String e' immutable.
Se ho capito bene, prova con StringBuffer
-- 
Giambo - Occhio al filtro antispam _e_ alla whitelist !


Anche io suggerisco di sostiruire le += della String con
StringBuffer.append(..)
mi ha appeta velocizzato (da 6secondi a 1) il trattamento di un file
testo
ciao

luciano996 wrote:

Non mi ero mai accorto che gli Stirng sono immutable.
E dire che li uso da anni indiscriminatamente.
Grazie per la precisazione :-)

 funzione += (o cat) vi era una gran perdita di tempo.
Ah, questo è sicuro. String è immutabile, ogni concatenazione genera una 
copia.
Usa StringBuffer adeguatamente preallocato, vedrai la differenza.

 Usa StringBuffer adeguatamente preallocato, vedrai la differenza.
Sì, ma il fatto che si ritrovi a maneggiare arry di byte nella lettura 
di un file di testo mi fa pensare che ci sia qualcosa di strano.
Utilizzando un BuffereReader avrebbe già le stringhe belle e pronte...


 pole
Strano maneggiare array di byte?
:-))))))))))))))))))))))))))))))
Hai mai fatto qualcosa che assomigli ad un parser?

 Hai mai fatto qualcosa che assomigli ad un parser?
Talvolta :)
Tu hai mai letto qualcosa che assomigli ai JavaDoc?
http://java.sun.com/j2se/1.5.0/docs/api/java/io/FileReader.html


 pole
Scusa ma non capisco dove vuoi arrivare: con un InputStream qualunquec  (che
sia buffered o meno o collegato a seriale o parallela o a filesystem....)
e` come se avessi a disposizione un unico grande buffer per effettuare le
letture di caratteri ma questo a livello di programmazione non e`
sufficiente a fare un parser qualsiasi.
Poi ognuno ha il proprio modo di programmare: se tu utilizzi una serie di
variabili intere o di iteratori per indicizzare in punti multipli
quell'inputStream sarranno affari tuoi se ci metti una settimana anziche' 1
giorno per far tornare i conti, ma in tal caso la programmazione ad oggetti
va a farsi fottere.
Ciao. Ciao.

Andrea wrote:
 > Scusa ma non capisco dove vuoi arrivare
 > [CUT]
Ehm... stavo cercando di spiegarti che per trattare i file di testo è 
conveniente utilizzare la gerarchia dei reader, che "salta" il concetto 
di byte presentandoti il contenuto direttamente sottoforma di caratteri 
(col BufferedReader addirittura stringhe).
Visto che il tuo problema risiedeva proprio nella costruzione delle 
suddette stringhe mi sembrava un suggerimento pertinente fartelo notare.
Poi, a 'sto punto, fai un po' come credi :)


 (col BufferedReader addirittura stringhe).
Ohhhh....ma davvero?
Quando vuoi prestazioni e` meglio usare piccoli semplici mattoncini
piuttosto che una varieta` di oggettoni che richiedono conversioni su
conversioni, rielaborazioni, istanziazione di altri oggetti usati sono in
parte ecc, ecc.
La SDK non e` male ma e` meglio non prenderla per oro colato.

 La SDK non e` male ma e` meglio non prenderla per oro colato.
Sě sě certo.
Dopo per favore fai sapere dove pubblichi i tuoi benchmark.  Magari alla 
Sun possono prenderli come spunto.
