On Sat, 05 Dec 2009 00:32:22 +0100, Pietro Battiston
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)
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
> 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
> >> wrote:
> >> > Il gio
On Fri, 04 Dec 2009 20:16:05 +0100, Pietro Battiston
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
>> wrote:
>> > Il giorno ven, 04/12/2009 alle 13.39 +0100, Daniele Varrazzo ha
>> > scritto:
>>
>> >> Io
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
> 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
> >>
On Fri, 04 Dec 2009 19:05:12 +0100, Pietro Battiston
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
è
>> controll
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 wrote:
> > 2009/12/4 Ernesto
> >
> >>
> >> oltre a questo (che cmq porterà i maggiori benefici) potremmo
> >> guadagnare
> >>> qualcosa anche con:
> >>>
> >>> Il link che ho
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á :-
2009/12/4 Massimo Capanni :
> 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 implement
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 ha scritto:
> 2009/12/4 Giovanni Marco Dall'Olio
>
>> Scusami, ma io questo lo farei con gawk (sempre che tu sia su un si
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 potrem
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 scriv
On Fri, 04 Dec 2009 14:38:44 +0100, Nicola Larosa
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 (qualch
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
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 istruis
> 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 apert
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 contemporaneamen
On Fri, 2009-12-04 at 13:39 +0100, Daniele Varrazzo wrote:
> On Fri, 4 Dec 2009 13:32:56 +0100, Marco Beri 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
On Fri, 2009-12-04 at 13:10 +0100, Daniele Varrazzo wrote:
> On Fri, 04 Dec 2009 12:59:52 +0100, David Mugnai 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 crear
2009/12/4 Daniele Varrazzo
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 s
On Fri, 4 Dec 2009 13:32:56 +0100, Marco Beri wrote:
> 2009/12/4 Ernesto
>
>>
>> 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 r
2009/12/4 Ernesto
>
> 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
> 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 veloc
On Fri, 4 Dec 2009 13:02:23 +0100, Marco Beri wrote:
> 2009/12/4 David Mugnai
> Il link che ho postato usa un approccio diverso. Usa delle liste in
memoria
> e scrive solo quando ha raggiunto una certa soglia.
+1
--
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com
___
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
On Fri, 04 Dec 2009 12:59:52 +0100, David Mugnai 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 dev
2009/12/4 David Mugnai
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 m
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
On Fri, 2009-12-04 at 12:40 +0100, Daniele Varrazzo wrote:
> On Fri, 4 Dec 2009 12:34:15 +0100, Ernesto 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
2009/12/4 Giovanni Marco Dall'Olio
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++)
>
N
2009/12/4 Ernesto
> 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.
>
Wi
2009/12/4 Ernesto :
> 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 > "outpu
On Fri, Dec 4, 2009 at 12:40 PM, Daniele Varrazzo wrote:
> On Fri, 4 Dec 2009 12:34:15 +0100, Ernesto 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.writ
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 ___
On Fri, 4 Dec 2009 12:34:15 +0100, Ernesto 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 15G
34 matches
Mail list logo
