[Python] split di file di grandi dimensioni

[Pietro Battiston]

Il giorno ven, 04/12/2009 alle 19.33 +0100, Daniele Varrazzo ha scritto:
> On Fri, 04 Dec 2009 19:05:12 +0100, Pietro Battiston <toobaz a email.it>
> wrote:
> > Il giorno ven, 04/12/2009 alle 13.39 +0100, Daniele Varrazzo ha scritto:
> 
> >> Io infatti avrei salvato tutti i dizionari dopo un numero prefissato di
> >> righe lette dal file di input. In questo modo l'occupazione di memoria
> è
> >> controllata e le prestazioni credo siano in linea (qualche file
> potrebbe
> >> avere poche righe, ma se su 1000 file aperti si scrivono 1M di righe
> >> statisticamente siamo lì). Credo sia anche molto più semplice da
> >> scrivere e
> >> meno soggetto ad errori.
> >> 
> > 
> > A me sembrerebbe più efficiente una via di mezzo: si scrive su file ogni
> > volta che si è raggiunta l'occupazione massima di memoria, ma si scrive
> > solo il file con più righe (da scrivere).
> > 
> > Significa semplicemente ogni volta che c'è da scrivere fare un max su
> > una lista di 1000 elementi (quella delle lunghezze, che può essere
> > tranquillamente creata al volo - len ha costo costante, giusto?), e non
> > mi sembra che possa avere un gran impatto, anche nel caso pessimo in cui
> > le righe destinate ai diversi file ricorrano con frequenze molto simili.
> 
> Questo non occupa una quantità di memoria costante: potrebbe essere
> difficile da controllare (metti se per esempio molti dei file si "gonfiano"
> ma poi restanto a lungo non chiamati in causa: questi resterebbero in ram
> per non far niente). 

Può essere meglio tenerli in RAM che fare 1000 "microscritture" su
disco.

> Ha anche alcune quadraticità (il singolo len è o(1) ma
> il max è o(n)).

'spe, 'spe

Poniamo che in memoria ci stiano anche solo un milione di righe, e che i
file siano mille: significa che al caso pessimo, ogni scrittura implica
almeno 1000 righe: ovvero, ogni 1000 righe lette/scritte farò 1000
chiamate a len ed una chiamata a max.

Certamente non aumenta l'ordine di grandezza, e penso che anzi in
termini quantitativi il tempo necessario in più sia trascurabile, perché
non c'è paragone tra una chiamata a len e la lettura+scrittura di una
riga (e questo è il caso pessimo).

> 
> Come caso pessimo la tua ricetta ha quello delle frequenze simili, La mia
> ha il caso in cui in ogni blocco di record letti (es. 1 milione) ogni
> record vada in un file distinto (es. 999 record in 999 file, tutti gli
> altri in uno solo). Il mio caso pessimo mi sembra più improbabile :)

Il mio caso pessimo l'ho descritto sopra, e mi sembra si comporti molto
meglio del tuo.

Parlare di probabilità dei casi pessimi non ha molto senso, se non la si
mette in rapporto con il costo degli stessi. Più in generale: posso
giustificare i ragionamenti al caso pessimo e quelli sulla media, ma a
parte questi due tipi di analisi non mi sembra si possa concludere
granché di sensato senza sapere qualcosa della struttura dei dati veri e
propri.

> 
> Anche come implementazione la mia ricetta mi sembra più semplice.
> 

certo

ciaociao

Pietro