Re: [Python] Consigli da voi esperti :-)
Carlos Catucci ha scritto: Beh sono in gran parte manuali scaricati da knowfree.net http://knowfree.net. Se mi date uno spazio dove poggiare tutto il materiale (sono due cartelle web e tradizionale, per rispettivi 763 e 402 Mb). Ah allora no, pensavo fossero link. Su knowfree.net ci si può sempre andare ;) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Consigli da voi esperti :-)
fossi in voi non lo farei alla luce del sole, quel knowfree.net sembra free as in robbery Onestamente io scarico da li copie pdf di manuali che acquisto, perche' per leggere la carta resta la carta (almeno fino a che non prendo un lettore con e-paper tipo l''Iliad) ma se devi fare un search rapido ... [o sei Johnny 5 (robot di Corto circuito) oppure sei nei guai], oppure al massimo di materiale introvabile da acquistare. Capita che un vecchio manuale, magari di una versione presedente, sia introvaile su Amazon, BN e compagni. A volte scarico prima per valutare la qualita' (esempio i manuali SAMS sono un attentato alla foresta amazzonica, su 800 pagine 650 potresti usarle al cesso, ha ragione il mio amico che dice che un manuale di informatica piu' spesso di 2 dita e' pieno di roba inutile) e se e' valido lo acquisto, altrimenti cestino il tutto. Non intendo incoraggiare o supportare la pirateria, ma visto che certi manuali non li trovo in libreria e non posso sfogliarli prima per vedere se contengono informazioni interessanti per me, e' un modo anche quello per fare una preview. E' come per i programmi shareware no? Provo e valuto, se mi piace compro senno' abbandono. Greetings JOKER Ltd. aka Carlos Catucci ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Consigli da voi esperti :-)
Carlos Catucci ha scritto: Onestamente io scarico da li copie pdf di manuali che acquisto, perche' per leggere la carta resta la carta (almeno fino a che non prendo un lettore con e-paper tipo l''Iliad) ma se devi fare un search rapido ... [o sei Johnny 5 (robot di Corto circuito) oppure sei nei guai], oppure al massimo di materiale introvabile da acquistare. Capita che un vecchio manuale, magari di una versione presedente, sia introvaile su Amazon, BN e compagni. A volte scarico prima per valutare la qualita' (esempio i manuali SAMS sono un attentato alla foresta amazzonica, su 800 pagine 650 potresti usarle al cesso, ha ragione il mio amico che dice che un manuale di informatica piu' spesso di 2 dita e' pieno di roba inutile) e se e' valido lo acquisto, altrimenti cestino il tutto. Non intendo incoraggiare o supportare la pirateria, ma visto che certi manuali non li trovo in libreria e non posso sfogliarli prima per vedere se contengono informazioni interessanti per me, e' un modo anche quello per fare una preview. E' come per i programmi shareware no? Provo e valuto, se mi piace compro senno' abbandono. La penso anche io cosi, anche perchè i libri costano soldini. E poi concordo con il dire: la carta e carta. Io studio più piacevolmente su carta che non su schermo. Ciao. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Unicode e ipython (era: Re: Usare Unicode e charset)
Ho seguito con interesse la discussione: io so gestire dignitosamente l'unicode nei programmi... ma ancora non ho mai capito come si comporta ipython a riguardo: pie...@vousci:~$ python Python 2.6.4 (r264:75706, Nov 2 2009, 14:44:17) [GCC 4.4.1] on linux2 Type help, copyright, credits or license for more information. import locale locale.getpreferredencoding() 'UTF-8' u=u'èà' print u èà , giustamente; invece... pie...@vousci:~/cancellami$ ipython Python 2.6.4 (r264:75706, Nov 2 2009, 14:44:17) Type copyright, credits or license for more information. IPython 0.10 -- An enhanced Interactive Python. ? - Introduction and overview of IPython's features. %quickref - Quick reference. help - Python's own help system. object? - Details about 'object'. ?object also works, ?? prints more. In [1]: import locale In [2]: locale.getpreferredencoding() Out[2]: 'UTF-8' In [3]: u=u'èà' In [4]: print u -- print(u) èà in che encoding mi sta parlando? E soprattutto perché? Pietro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Unicode e ipython (era: Re: Usare Unicode e charset)
Pietro Battiston wrote: in che encoding mi sta parlando? E soprattutto perché? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409710 http://lists.ipython.scipy.org/pipermail/ipython-tickets/2007-April/33.html -- This e-mail (and any attachment(s)) is strictly confidential and for use only by intended recipient(s). Any use, distribution, reproduction or disclosure by any other person is strictly prohibited. The content of this e-mail does not constitute a commitment by the Company except where provided for in a written agreement between this e-mail addressee and the Company. If you are not an intended recipient(s), please notify the sender promptly and destroy this message and its attachments without reading or saving it in any manner. Any non authorized use of the content of this message constitutes a violation of the obligation to abstain from learning of the correspondence among other subjects, except for more serious offence, and exposes the person responsible to the relevant consequences. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 4 Dec 2009 12:34:15 +0100, Ernesto e.pica...@unical.it wrote:
Per ora il modo più semplice che ho trovato è:
import os
f=open(infile)
for i in f:
l=(i.strip()).split(\t)
out=open(l[2]+.txt,a)
out.write(i)
out.close()
f.close()
Lanciato su un file di 15GB il tempo necessario per completare il
tutto è superiore ai 2 giorni.
C'è un modo per velocizzare il processo?
Perchè apri e chiudi i file ad ogni riga? Ogni volta gli fai flushare il
buffer. Lasciali aperti:
# NON TESTATO
files = {}
for c in ABC:
files[c] = open(c + .txt,a)
f=open(infile)
for i in f:
l=(i.strip()).split(\t)
files[l[2]].write(i)
f.close()
for f in files.values():
f.close()
--
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
Perchè apri e chiudi i file ad ogni riga? Ogni volta gli fai flushare il buffer. Lasciali aperti: Ho provato a lasciarli aperti ma ho ottenuto un errore che mi indicava che avevo più di 24 file aperti. In realtà i file di output che mi aspetto sono più di 1000. Ernesto ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, Dec 4, 2009 at 12:40 PM, Daniele Varrazzo p...@develer.com wrote:
On Fri, 4 Dec 2009 12:34:15 +0100, Ernesto e.pica...@unical.it wrote:
Per ora il modo più semplice che ho trovato è:
import os
f=open(infile)
for i in f:
l=(i.strip()).split(\t)
out=open(l[2]+.txt,a)
out.write(i)
out.close()
f.close()
Lanciato su un file di 15GB il tempo necessario per completare il
tutto è superiore ai 2 giorni.
C'è un modo per velocizzare il processo?
Perchè apri e chiudi i file ad ogni riga? Ogni volta gli fai flushare il
buffer. Lasciali aperti:
# NON TESTATO
files = {}
for c in ABC:
files[c] = open(c + .txt,a)
f=open(infile)
for i in f:
l=(i.strip()).split(\t)
files[l[2]].write(i)
f.close()
for f in files.values():
f.close()
Aggiungo che su file di queste dimensioni ti conviene fare buffered
reading/writing. Se usi python 2.6 vedi TextIOWrapper
(http://docs.python.org/library/io.html).
--
(+39) 349 05 37 906
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
2009/12/4 Ernesto e.pica...@unical.it:
import os
f=open(infile)
for i in f:
l=(i.strip()).split(\t)
out=open(l[2]+.txt,a)
out.write(i)
out.close()
f.close()
Scusami, ma io questo lo farei con gawk (sempre che tu sia su un sistema unix)
$: gawk '{print $0 output_$3.txt}' input.txt
Per esperienza, i tool unix sono molto piu' veloci di quanto tu possa
fare in python (beh, sono scritti in C o C++)
Lanciato su un file di 15GB il tempo necessario per completare il
tutto è superiore ai 2 giorni.
C'è un modo per velocizzare il processo?
Grazie,
Ernesto
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
--
Giovanni Dall'Olio, phd student
Department of Biologia Evolutiva at CEXS-UPF (Barcelona, Spain)
My blog on bioinformatics: http://bioinfoblog.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
2009/12/4 Ernesto e.pica...@unical.it Perchè apri e chiudi i file ad ogni riga? Ogni volta gli fai flushare il buffer. Lasciali aperti: Ho provato a lasciarli aperti ma ho ottenuto un errore che mi indicava che avevo più di 24 file aperti. In realtà i file di output che mi aspetto sono più di 1000. Windows? No Linuxtour? Ahiahiahaihi :-) In Linux il limite è 1024. Mi dicono che con XP sia 512, ma purtroppo in Windows non c'è il comodo metodo resource per verificarlo: import resource resource.getrlimit(resource.RLIMIT_NOFILE) (1024L, 1024L) Un suggerimento interessante lo trovi qui: http://bytes.com/topic/python/answers/766892-too-many-open-files#post3057405 Ciao. Marco. -- http://ThinkCode.TV - Screencast e videocorsi di programmazione http://stacktrace.it - Aperiodico di resistenza informatica http://beri.it - Blog di una testina di vitello ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
2009/12/4 Giovanni Marco Dall'Olio dalloli...@gmail.com
Scusami, ma io questo lo farei con gawk (sempre che tu sia su un sistema
unix)
$: gawk '{print $0 output_$3.txt}' input.txt
Per esperienza, i tool unix sono molto piu' veloci di quanto tu possa
fare in python (beh, sono scritti in C o C++)
Nel caso può provare con cygwin che ha anche lui gawk.
Ciao.
Marco.
--
http://ThinkCode.TV - Screencast e videocorsi di programmazione
http://stacktrace.it - Aperiodico di resistenza informatica
http://beri.it - Blog di una testina di vitello
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 2009-12-04 at 12:40 +0100, Daniele Varrazzo wrote: On Fri, 4 Dec 2009 12:34:15 +0100, Ernesto e.pica...@unical.it wrote: Per ora il modo più semplice che ho trovato è: import os f=open(infile) for i in f: l=(i.strip()).split(\t) out=open(l[2]+.txt,a) out.write(i) out.close() f.close() Lanciato su un file di 15GB il tempo necessario per completare il tutto è superiore ai 2 giorni. C'è un modo per velocizzare il processo? Perchè apri e chiudi i file ad ogni riga? Ogni volta gli fai flushare il buffer. Lasciali aperti: oltre a questo (che cmq porterà i maggiori benefici) potremmo guadagnare qualcosa anche con: 1) aprire il file da 15GB in modalità binaria (utile solo se siamo sotto windows e forse anche sotto mac) 2) provare ad aumentare il buffer dei file (forse più utile quello in scrittura?) 3) se le linee nel file hanno lunghezza fissa non usare il for ma andare di f.read(qualchekb) bye signature.asc Description: This is a digitally signed message part ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 2009-12-04 at 12:49 +0100, Ernesto wrote: Perchè apri e chiudi i file ad ogni riga? Ogni volta gli fai flushare il buffer. Lasciali aperti: Ho provato a lasciarli aperti ma ho ottenuto un errore che mi indicava che avevo più di 24 file aperti. In realtà i file di output che mi aspetto sono più di 1000. puoi aumentare il numero di file aperti contemporanemante, su che os stai lavorando? signature.asc Description: This is a digitally signed message part ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
2009/12/4 David Mugnai d...@gnx.it oltre a questo (che cmq porterà i maggiori benefici) potremmo guadagnare qualcosa anche con: Il link che ho postato usa un approccio diverso. Usa delle liste in memoria e scrive solo quando ha raggiunto una certa soglia. Solo due file aperti al massimo ed esecuzione molto veloce (infatti scrive un blocco di molte righe e non una per volta). Ciao. Marco. -- http://ThinkCode.TV - Screencast e videocorsi di programmazione http://stacktrace.it - Aperiodico di resistenza informatica http://beri.it - Blog di una testina di vitello ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 04 Dec 2009 12:59:52 +0100, David Mugnai d...@gnx.it wrote: 3) se le linee nel file hanno lunghezza fissa non usare il for ma andare di f.read(qualchekb) file.__iter__ fa questo dietro le quinte. Infatti se vuoi davvero creare un programma filtro in Python devi non solo usare python -u, ma devi anche sostituire il for con: while 1: line = f.readline() if not line: break ... -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
puoi aumentare il numero di file aperti contemporanemante, su che os stai lavorando? Su OS X 10.5.___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
oltre a questo (che cmq porterà i maggiori benefici) potremmo guadagnare qualcosa anche con: Il link che ho postato usa un approccio diverso. Usa delle liste in memoria e scrive solo quando ha raggiunto una certa soglia. Solo due file aperti al massimo ed esecuzione molto veloce (infatti scrive un blocco di molte righe e non una per volta). Stavo tentando un approccio simile. In pratica potrei creare un dizionario dove associare ad ogni valore una lista con le singole righe e poi scriverle su file se la lista è uguale ad un numero prefissato di righe. ernesto ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
2009/12/4 Ernesto e.pica...@unical.it oltre a questo (che cmq porterà i maggiori benefici) potremmo guadagnare qualcosa anche con: Il link che ho postato usa un approccio diverso. Usa delle liste in memoria e scrive solo quando ha raggiunto una certa soglia. Solo due file aperti al massimo ed esecuzione molto veloce (infatti scrive un blocco di molte righe e non una per volta). Stavo tentando un approccio simile. In pratica potrei creare un dizionario dove associare ad ogni valore una lista con le singole righe e poi scriverle su file se la lista è uguale ad un numero prefissato di righe. Ok, attento in uscita dal loop: devi scrivere le ultime righe rimaste nel dizionario. E ricordati di avere un limite massimo di righe tale da gestire anche la situazione peggiore:\ MAX_LENGTH * MAX_NUM_FILE * (MAX_RIGHE - 1) Murphy è sempre in agguato :-) Ciao. Marco. -- http://ThinkCode.TV - Screencast e videocorsi di programmazione http://stacktrace.it - Aperiodico di resistenza informatica http://beri.it - Blog di una testina di vitello ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 2009-12-04 at 13:10 +0100, Daniele Varrazzo wrote: On Fri, 04 Dec 2009 12:59:52 +0100, David Mugnai d...@gnx.it wrote: 3) se le linee nel file hanno lunghezza fissa non usare il for ma andare di f.read(qualchekb) file.__iter__ fa questo dietro le quinte. Infatti se vuoi davvero creare un programma filtro in Python devi non solo usare python -u, ma devi anche sostituire il for con: while 1: line = f.readline() if not line: break ... non mi sono spiegato, se le righe hanno lunghezza prefissata puoi leggere a blocchi, risparmiare la split per trovare il carattere e risparmiare alla readline di python di cercare il \n signature.asc Description: This is a digitally signed message part ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 2009-12-04 at 13:39 +0100, Daniele Varrazzo wrote: On Fri, 4 Dec 2009 13:32:56 +0100, Marco Beri marcob...@gmail.com wrote: [snip] Ok, attento in uscita dal loop: devi scrivere le ultime righe rimaste nel dizionario. E ricordati di avere un limite massimo di righe tale da gestire anche la situazione peggiore:\ MAX_LENGTH * MAX_NUM_FILE * (MAX_RIGHE - 1) Murphy è sempre in agguato :-) 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. 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 :) signature.asc Description: This is a digitally signed message part ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 2009-12-04 at 13:12 +0100, Ernesto wrote: puoi aumentare il numero di file aperti contemporanemante, su che os stai lavorando? Su OS X 10.5. quindi uno unix based, ci sarà sicuramente un comando per aumentare il numero permesso di file aperti contemporaneamente, magari è proprio ulimit, ma io e OS/X siamo su due pianeti diversi quindi passo la palla a chi lo conosce per bene. signature.asc Description: This is a digitally signed message part ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
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). -- Nicola Larosa - http://www.tekNico.net/ Exposing real pre-emptive threading with shared mutable data structures to application programmers is wrong. [...] Threads are a recipe for deadlocks, race conditions, horrible non-reproducible bugs that take endless pain to find, and hard-to-diagnose performance problems. - Tim Bray, September 2009 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
Nicola Larosa ha scritto: [...] 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 :) Con quello istruisci il buffering fatto dall'IO in Python (basato su stdio del C), non il sistema operativo. Non c'è modo diretto per dire al kernel quanta memoria usare per il buffering di un file, che io sappia (e di certo POSIX non lo prevede). [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
Manlio Perillo ha scritto: Nicola Larosa ha scritto: [...] David Mugnai wrote: Ah, scusa, ho riposto a te invece che a David. Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 04 Dec 2009 14:38:44 +0100, Nicola Larosa n...@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 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 2009-12-04 at 15:08 +0100, Daniele Varrazzo wrote: [snip] No, non stiamo reinventando i buffer: li stiamo usando meglio. hmm, più che meglio forse in maniera diversa (e magari più opportuna a seconda del problema) 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. se il limite è impostato ad capocchiam non vedo un problema ad utilizzare ulimit; rileggendo una mail dell'OP, lui dice: In realtà i file di output che mi aspetto sono più di 1000. che è un paio di ordini di grandezza sopra a 24 quindi è molto probabile che una strategia per limitare i file aperti serva in ogni caso. signature.asc Description: This is a digitally signed message part ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 2009-12-04 at 14:56 +0100, Manlio Perillo wrote: Nicola Larosa ha scritto: [...] 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 :) Con quello istruisci il buffering fatto dall'IO in Python (basato su stdio del C), non il sistema operativo. Non c'è modo diretto per dire al kernel quanta memoria usare per il buffering di un file, che io sappia (e di certo POSIX non lo prevede). hai ragione! mi ricordavo male. Probabilmente quel buffer influenza il numero di flush che python chiama, ma se queste finiscano sul disco oppure no lo decide il kernel. signature.asc Description: This is a digitally signed message part ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
Gawk per Windows funziona discretamente bene.
Mi ha processato file di 900 mega in pochi secondi liberandomi di
molto lavoro manuale :)
Il 04 dicembre 2009 12.59, Marco Beri marcob...@gmail.com ha scritto:
2009/12/4 Giovanni Marco Dall'Olio dalloli...@gmail.com
Scusami, ma io questo lo farei con gawk (sempre che tu sia su un sistema
unix)
$: gawk '{print $0 output_$3.txt}' input.txt
Per esperienza, i tool unix sono molto piu' veloci di quanto tu possa
fare in python (beh, sono scritti in C o C++)
Nel caso può provare con cygwin che ha anche lui gawk.
Ciao.
Marco.
--
http://ThinkCode.TV - Screencast e videocorsi di programmazione
http://stacktrace.it - Aperiodico di resistenza informatica
http://beri.it - Blog di una testina di vitello
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
2009/12/4 Massimo Capanni massimo.capa...@gmail.com:
Gawk per Windows funziona discretamente bene.
Mi ha processato file di 900 mega in pochi secondi liberandomi di
molto lavoro manuale :)
effettivamente sì, se il problema postato dall'op é per questioni di
lavoro io utilizzerei gawk, senza perdere tempo a implementare
qualcosa che esiste giá :-)
Non sono sicuro ma mi sembra che almeno awk sia installato di default
sui mac. In questo caso il comando diventa semplicemente:
awk '{print $0 output_$3.txt}' input.txt
Personalmente l'ho utilizzato per problemi simili e su quantitá di
dati simili a quelli della domanda (10, 15 GB) e non ho mai dovuto
aspettare piu' di una ora.
Al massimo, se anche gawk dovesse essere lento, conviene semplificare
il problema alla base, ovvero: splittare il file in pezzi piu' piccoli
(comando split) e correrlo in parallelo, oppure ordinarlo (sort -k),
sempre che non sia importante mantenere l'ordine delle righe
originale.
Il 04 dicembre 2009 12.59, Marco Beri marcob...@gmail.com ha scritto:
2009/12/4 Giovanni Marco Dall'Olio dalloli...@gmail.com
Scusami, ma io questo lo farei con gawk (sempre che tu sia su un sistema
unix)
$: gawk '{print $0 output_$3.txt}' input.txt
Per esperienza, i tool unix sono molto piu' veloci di quanto tu possa
fare in python (beh, sono scritti in C o C++)
Nel caso può provare con cygwin che ha anche lui gawk.
Ciao.
Marco.
--
http://ThinkCode.TV - Screencast e videocorsi di programmazione
http://stacktrace.it - Aperiodico di resistenza informatica
http://beri.it - Blog di una testina di vitello
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
--
Giovanni Dall'Olio, phd student
Department of Biologia Evolutiva at CEXS-UPF (Barcelona, Spain)
My blog on bioinformatics: http://bioinfoblog.it
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
Il giorno ven, 04/12/2009 alle 13.39 +0100, Daniele Varrazzo ha scritto: On Fri, 4 Dec 2009 13:32:56 +0100, Marco Beri marcob...@gmail.com wrote: 2009/12/4 Ernesto e.pica...@unical.it oltre a questo (che cmq porterà i maggiori benefici) potremmo guadagnare qualcosa anche con: Il link che ho postato usa un approccio diverso. Usa delle liste in memoria e scrive solo quando ha raggiunto una certa soglia. Solo due file aperti al massimo ed esecuzione molto veloce (infatti scrive un blocco di molte righe e non una per volta). Stavo tentando un approccio simile. In pratica potrei creare un dizionario dove associare ad ogni valore una lista con le singole righe e poi scriverle su file se la lista è uguale ad un numero prefissato di righe. Ok, attento in uscita dal loop: devi scrivere le ultime righe rimaste nel dizionario. E ricordati di avere un limite massimo di righe tale da gestire anche la situazione peggiore:\ MAX_LENGTH * MAX_NUM_FILE * (MAX_RIGHE - 1) Murphy è sempre in agguato :-) 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. Pietro ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 04 Dec 2009 19:05:12 +0100, Pietro Battiston too...@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). Ha anche alcune quadraticità (il singolo len è o(1) ma il max è o(n)). 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 :) Anche come implementazione la mia ricetta mi sembra più semplice. -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
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 too...@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 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 04 Dec 2009 20:16:05 +0100, Pietro Battiston too...@email.it wrote: 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 too...@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. In che senso può essere? A parte che è un'affermazione un po' arbitraria (come tutto questo discorso peraltro, ma si fa per giocare) stai confrontando due algoritmi paragonando l'occupazione di memoria di uno col numero di accessi al disco di un altro: non è comparare le stesse cose. Il mio algoritmo (non testato) è def split_file(file_name): parts = defaultdict(list) input = iter(open(input_file)) try: while 1: # leggi un blocco di record for i in xrange(RECORDS_TO_READ): record = input.next() parts[get_filename(record)].append(record) # Scrivi i file letti write_files(parts) # Fine file: scrivi i record che restano except StopIteration: write_files(parts) def write_files(parts) # questo consuma il dizionario for filename in parts.keys(): open(filename, 'a').write( ''.join(parts.pop(k))) Ipotizziamo che ci sono n record ed m file in cui scrivere. Diciamo per mettere dei numeri che n=1e9 e m=1e3. In queste condizioni setterei RECORDS_TO_READ = 1e6 (= k). Io dico che questo algoritmo ha occupazione di memoria limitata ed effettua il minimo numero di scritture in presenza di dati normali (ovvero circa n / k * m ~= 1e6). L'occupazione di memoria costante è la prima preoccupazione a fronte di un input di grande dimensioni. 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). Potresti scrivere un accenno del tuo algoritmo? Non ho capito esattamente quando vuoi chiamare il max. Ovvero: quando aggiungi un record ad una lista, se questo record ha superato una cera soglia (es. 1000) tu scrivi questi record nel file e svuoti la lista? oppure ogni k record che leggi in input cerchi la lista più lunga e scrivi il file corrispondente (ma in questo modo ogni k record ne scrivi solo k / m in media, quindi l'occupazione di memoria continua a crescere)... Probabilmente hai ragione dicendo che il max abbia un peso trascurabile visto che il tutto è i/o bound, ma l'occupazione di memoria mi sembra poco controllata. Se puoi accennarmi in codice quello che vuoi fare forse capisco meglio. 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
Re: [Python] split di file di grandi dimensioni
Il giorno ven, 04/12/2009 alle 23.49 +0100, Daniele Varrazzo ha scritto:
On Fri, 04 Dec 2009 20:16:05 +0100, Pietro Battiston too...@email.it
wrote:
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 too...@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.
In che senso può essere? A parte che è un'affermazione un po' arbitraria
(come tutto questo discorso peraltro, ma si fa per giocare) stai
confrontando due algoritmi paragonando l'occupazione di memoria di uno col
numero di accessi al disco di un altro: non è comparare le stesse cose.
Il mio algoritmo (non testato) è
def split_file(file_name):
parts = defaultdict(list)
input = iter(open(input_file))
try:
while 1:
# leggi un blocco di record
for i in xrange(RECORDS_TO_READ):
record = input.next()
parts[get_filename(record)].append(record)
# Scrivi i file letti
write_files(parts)
# Fine file: scrivi i record che restano
except StopIteration:
write_files(parts)
def write_files(parts)
# questo consuma il dizionario
for filename in parts.keys():
open(filename, 'a').write(
''.join(parts.pop(k)))
Ipotizziamo che ci sono n record ed m file in cui scrivere. Diciamo per
mettere dei numeri che n=1e9 e m=1e3. In queste condizioni setterei
RECORDS_TO_READ = 1e6 (= k). Io dico che questo algoritmo ha occupazione di
memoria limitata ed effettua il minimo numero di scritture in presenza di
dati normali (ovvero circa n / k * m ~= 1e6). L'occupazione di memoria
costante è la prima preoccupazione a fronte di un input di grande
dimensioni.
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).
Potresti scrivere un accenno del tuo algoritmo?
Prima di sprecare (potenzialmente) parole, lo faccio. Poi se c'è
qualcosa che non è chiaro, chiarirò:
def estrai_target(linea):
# deduci dalla linea in che file deve andare
...
def estrai_contenuto(linea):
# deduci dalla linea cosa va scritto nel file
...
class Lettore():
def __init__(self):
self.contatore_linee = 0
self.diz = {}
file_in = open(file_in)
while True:
linea = file_in.readline()
if linea:
self.processa_linea(linea)
else:
break
# Finito di parsare il file, facciamo un flush
for target in self.diz:
self.scrivi_su_file_e_svuota_lista(target)
# Finito
def processa_linea(linea):
contenuto = estrai_contenuto(linea)
target = estrai_target(linea)
if not target in self.diz:
self.diz[target] = []
self.diz[target].append(contenuto)
self.contatore_linee += 1
if self.contatore_linee MEMORIA_MAX:
# Si arriva qui al più N_RIGHE * (N_FILE/MEMORIA_MAX) volte
# (dignitoso purché N_FILE**2 = MEMORIA_MAX, dato
Re: [Python] split di file di grandi dimensioni
On Sat, 05 Dec 2009 00:32:22 +0100, Pietro Battiston too...@email.it wrote: def processa_linea(linea): contenuto = estrai_contenuto(linea) target = estrai_target(linea) if not target in self.diz: self.diz[target] = [] self.diz[target].append(contenuto) self.contatore_linee += 1 if self.contatore_linee MEMORIA_MAX: # Si arriva qui al più N_RIGHE * (N_FILE/MEMORIA_MAX) volte # (dignitoso purché N_FILE**2 = MEMORIA_MAX, dato che # le righe seguenti hanno costo grosso modo N_FILE) popolarità_massima = 0 for un_target, sua_lista in zip(self.diz, self.diz.values): popolarità = len(sua_lista) if popolarità popolarità_massima: il_più_popolare = un_target popolarità_massima = popolarità self.scrivi_su_file_e_svuota_lista(il_più_popolare) self.contatore_linee -= popolarità_massima Ho capito: praticamente mantieni il numero di righe memorizzate compreso tra il massimo e il massimo meno la dimensione della lista maggiore. Il fatto è che mi sembra parecchio più complicato pur non risolvendo alcun problema sostanziale: così diminuisci il numero di scritture in caso di distribuzioni distanti dall'uniformità al limite del patologico, ma già con la versione semplice dell'algoritmo le scritture sono passate (per i numeri usati negli esempi fatti finora) dalle originali 1e9 a 1e6: mi sembra che questo sia uno di quei casi in cui il meglio è nemico del bene. -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
