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
Ciao a tutti,
sono alle prese con uno script che deve effettuare lo split di un
grosso file di circa 15 GB in un set di file di output.
Premetto che le righe presenti nel file devono essere indirizzate ad
uno specifico file di output in accordo all'informazione che portano.
Mi spiego meglio. O
35 matches
Mail list logo
