[Python] split di file di grandi dimensioni

[Daniele Varrazzo]

On Fri, 04 Dec 2009 14:38:44 +0100, Nicola Larosa <nico a tekNico.net>
wrote:
>> Daniele Varrazzo wrote:
>>> 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.
> 
> David Mugnai wrote:
>> non stiamo reinventando quello che già fa il sistema operativo con il 
>> file buffer? invece di scrivere logica addizionale che mima quello che
>> fa già il kernel potremmo provare ad aprire i file con bufsize=10M :)
> 
> Esattamente.
> 
> E aumentare il numero di file che si possono aprire insieme non è un
> problema (24 è un limite ridicolo, tra l'altro, c'è qualcos'altro in
> ballo).

No, non stiamo reinventando i buffer: li stiamo usando meglio.

24 è un limite basso, ma se il numero di file potenzialmente da scrivere è
estremamente alto, scrivere un programma che garantisca l'uso di un numero
controllato di file aperti mi sembra sensibile quanto scrivere un programma
che non carichi tutto il file in memoria. Uno script che per girare ha
bisogno che gli venga impostato ulimit mi sembra abbia dei problemi, quanto
uno che per processare 1GB di file ha bisogno di 1GB di memoria.

Fatto questo, un bufsize di dimensione esagerata non credo farà molta
differenza rispetto al buffer normale (che mi sembra essere di 8KB). L'OP
potrebbe fare una prova per verificare (basta aprire i file con open(name,
'a', 1024*1024) per aprire un file con un buffer di 1MB): secondo me
cambierà poco rispetto al default, ma preferisco parlino i numeri.

-- 
Daniele Varrazzo - Develer S.r.l. 
http://www.develer.com