Come posso velocizzare l'elaborazione di dati a larghezza fissa di Perl?

Question

Abbiamo un corpo maturo di codice che carica i dati da file in un database. Ci sono diversi formati di file; sono tutti campi a larghezza fissa.

Parte del codice utilizza la funzione Perl unpack() per leggere i campi dai dati di input in variabili del pacchetto. La logica aziendale è quindi in grado di riferirsi a questi campi in un modo "leggibile".

Il codice di lettura file viene generato da una descrizione di formato una volta, prima di leggere un file.

Nella forma schizzo, il codice generato assomiglia a questo:

while (<>) { 

    # Start of generated code. 

    # Here we unpack 2 fields, real code does around 200. 
    ($FIELDS::transaction_date, $FIELDS::customer_id) = unpack q{A8 A20}; 

    # Some fields have leading space removed 
    # Generated code has one line like this per affected field. 
    $FIELDS::customer_id =~ s/^\s+//; 

    # End of generated code. 

    # Then we apply business logic to the data ... 
    if ($FIELDS::transaction_date eq $today) { 
     push @fields, q{something or other}; 
    } 

    # Write to standard format for bulk load to the database. 
    print $fh join('|', @fields) . q{\n} or die; 
} 

Profiling il codice rivela che circa il 35% del tempo viene speso nella decomprimere e striscia leader-spazio. Il tempo rimanente è dedicato alla convalida e alla trasformazione dei dati e alla scrittura nel file di output.

Sembra che non ci sia una singola parte della business logic che richiede più dell'1-2% del tempo di esecuzione.

La domanda è: possiamo liberare un po 'più la velocità dal disimballaggio e dallo spogliamento dello spazio in qualche modo? Preferibilmente senza dover rifattorizzare tutto il codice che fa riferimento alle variabili del pacchetto FIELDS.

EDIT:

Nel caso in cui si fa la differenza

$ perl -v 
This is perl, v5.8.0 built for PA-RISC1.1 

Answer 1

Sì. Estrarre usando substr è probabilmente il modo più veloce per farlo. Ovvero:

$FIELDS::transaction_date = substr $_, 0, 8; 
$FIELDS::customer_id  = substr $_, 8, 20; 

è probabile che sia più veloce. Ora, se scrivessi questo codice a mano, non rinuncerei a unpack, ma se stai generando il codice, potresti anche dargli un colpo e misurarlo.

Vedere anche le risposte a Is Perl’s unpack() ever faster than substr()?

Quanto a nudo gli spazi iniziali, s/^\s+// è probabile che sia il metodo più veloce.

Aggiornamento: È difficile dire qualcosa di definito senza essere in grado di eseguire benchmark. Tuttavia, come su:

my $x = substr $_, 0, 8; 

per i campi che non hanno bisogno di alcun taglio e

my ($y) = substr($_, 8, 20) =~ /\A\s+(.+?)\s+\z/; 

che non hanno bisogno di tagliare?

Answer 2

Ho effettivamente affrontato questo problema più e più volte. Unpack is better than substr.

Per quanto riguarda gli spazi di spogliamento, sei praticamente fregato. Quella modifica regex è il modo "ufficiale" per farlo. Potresti essere in grado di guadagnare un po 'di efficienza perfezionando le istruzioni di decompressione (supponendo che nessun dato sia più lungo di 4 cifre, perché decomprimere le 12 cifre complete del campo?), Ma in caso contrario, l'analisi è solo un p.i.t.a.

Buona fortuna con i dati flat. Frying junk legacy, come lo odio.

Answer 3

Sei sicuro di essere associato a questa attività? Il calcolo è abbastanza semplice da sospettare che l'intero processo sia probabilmente legato all'I/O. In tal caso, l'ottimizzazione per una decompressione più veloce non ti farà guadagnare molto tempo.

Nel caso in cui il processore sia effettivamente collegato, il problema descritto sembra abbastanza parallelizzabile, ma ovviamente il diavolo si trova nei dettagli del calcolo aziendale.

Answer 4

Questo potrebbe essere anche qualcosa per XS - in modo da utilizzare una funzione C per modificare i dati. Potrei immaginare che questo è molto più veloce di qualsiasi altra cosa in quanto è possibile controllare manualmente quando i dati vengono realmente copiati.
Il processo di compilazione diventerà più difficile in quanto si ha una dipendenza dal compilatore C e richiederà ulteriori passaggi di integrazione.

Answer 5

Basta farlo andare in parallelo. È banale, e su qualsiasi macchina anche lontanamente moderna sarà più veloce.

Answer 6

Il benchmark di una versione del nostro codice basata su sub ha suggerito che potrebbe essere circa il 50% più veloce rispetto al nostro disimballaggio esistente. Confrontando i codici in atto nell'applicazione effettiva, la versione substr ha permesso una riduzione del 16% del tempo di esecuzione. Questo è vicino a quello che speravamo in base al benchmark e alla profilazione cui fa riferimento la domanda.

Questa ottimizzazione potrebbe essere utile per noi. Ma, abbiamo una migrazione verso un nuovo sistema operativo all'orizzonte, quindi aspetteremo e vedremo come i codici funzionano lì prima di procedere. Abbiamo aggiunto un test per tenere d'occhio i benchmark comparativi.

Il linguaggio che abbiamo ora è:

$FIELDS::transaction_date = substr($_, 0, 8) || ''; 
$FIELDS::transaction_date =~ s/\s+\z//; 
$FIELDS::customer_id = substr($_, 8, 20) || ''; 
$FIELDS::customer_id =~ s/\s+\z//; 

Seguito da selettiva rimozione leader spazio come prima.

Grazie per tutte le risposte finora. Accetterò Sinan perché ha funzionato per noi, nonostante appaia essere "semplicemente sbagliato".