On 26 Nov 2002 at 22:35, Davide Bolcioni wrote:
> > In questo contesto è quello che caricherò in memoria quando lo leggo.
> In tal caso, l'unica è leggere fino a che non arrivi in fondo. Ma vedi
> sotto.
mmm dipende da cosa ti aspetti... devo esemplificare o ti fidi?
Una "previsione" potrebbe ridurre di molto il costo di riallocazioni e
spostamenti in memoria.
> Ci deve essere qualcosa in ciò che scrivo che non ti risulta chiaro. Se
> le istruzioni le scrivi una di seguito all'altra piuttosto che in una
> funzione distinta, che differenza pensi che faccia ? Se mi rispondi che
suppongo a fine email tu abbia colto la differenza che mi fa.
> è più efficiente suggerisco un crash course sulle CPU moderne, che si
> può riassumere in: un salto condizionato mal predetto costa circa quanto
Ho presente... ma ho avuto un'infanzia difficile.
> Secondo me, in realtà ti serve mmap(). Si tratta di un concetto che non
> è portabile e quindi non è coperto dalla libreria standard; basta
> incapsularlo in una classe (primitiva di supporto) e introdurre una
Adesso rileggo il seguito... ma mmap suona _difficile_ da incapsulare
in maniera tale che la funzione ottenuta sia facilmente riscrivibile
senza massacrare il resto del codice e mi sembra un pessimo compromesso
portabilità/efficienza/manutenibilità.
mmm veramente mi sembra proprio che mmap non mi serva perchè length lo
devo dare io
Preferisco un size_forecast() con dentro seekg() tellg() e poi si
vedrà.
Adesso andiamo avanti... la sciolina la metto dopo.
Premature optimization is the root of all evil. (Knuth)
--
Salve
Ivan Sergio Borgonovo
http://www.webthatworks.it/
uniq life || sleep 24h
|