dba_qcfilter performance

[edigiacomo]

dba_qcfilter is a huge bottleneck when importing data in a dbadb.

$ time dbadb import --fast --overwrite --wipe-first --dsn=sqlite:/dev/shm/test.db < test.bufr 

real    0m16.450s
user    0m16.010s
sys     0m0.344s

$ time dba_qcfilter < test.bufr | dbadb import --fast --overwrite --wipe-first --dsn=sqlite:/dev/shm/test.db
real    10m56.730s
user    11m8.797s
sys     0m2.109s

The second command is ~37 times slower and in some scenarios this is too much.

We talked about this problem 2 years ago (mail subject: "[libsim] Performance di dba_qcfilter") and, if I understand correctly @pat1's response, the problem could be the sqlite in-memory database creation for each BUFR read from stdin.

To mitigate the problem, could it be a good idea adding an option to dbq_qcfilter to optionally work with a file? In that case, the data could be loaded in a single in-memory db: the memory problem could be solved upstream, splitting the input data in chunks (e.g. arki-xargs).

The fix would be backward-compatible because, without arguments, the command can read the data fron stdin.

Something like:

# This command load all the BUFR messages in the same in-memory dbadb and the output the result
$ dba_qcfilter test.bufr > test-filtered.bufr

# This command created an in-memory db for each BUFR message (the actual behaviour)
$ dba_qcfilter < test.bufr > test-filtered.bufr

[brancomat]

To sum up the 2019-07-09 internal e-mail:
@edigiacomo rewrote dba_qcfilter in python with a performance improvement of 5x/8x, and it's currently distributed with dballe:
https://github.com/ARPA-SIMC/dballe/blob/python-examples/examples/qcfilter.py

questions still unanswered:

• is this ok?
• should it be distributed in libsim package, in dballe package or in another independent package?
• should it be updated in a python module?

[edigiacomo]

I propose to add the program to this repository (libsim) as a CLI and replace the libsim-based dba_qcfilter. As you are all aware, the only problem is to keep in sync the quality control policy between this script and libsim.

If a Python API is needed, we should collect the requirements.

[pat1]

faccio una proposta esplorativa:
includere qcfilter in libsim mi parrebbe non ottimale essendo libsim solo fortran e dovendo essere questo l'unico pezzo in python con forti dipendenze da altri moduli
ipotizzando la necessità futura di sviluppare altri tools pure python specifici del SIMC a corredo di dballe creerei un pacchetto dedicato con qcfilter e in futuro altro.
Io prevederei anche delle API (semplici) del modulo qcfilter
mi pare che l'attuale qcfilter non soddisfi però tutte le funzionalità di dba_qcfilter

[edigiacomo]

Una considerazione: libsim dipende già da dballe e quindi si aggiungerebbero come dipendenze solo python3 e python3-dballe - e volendo si potrebbe disabilitare a tempo di compilazione da configure se non trova le suddette dipendenze oppure con una flag se si vuole un pacchetto "minimale" (e quindi tutto rimarrebbe uguale ad ora).

Dico questo solo per amore di completezza, non ho forti opinioni in tema. L'unica cosa è che se vogliamo fare un pacchetto a parte si deve scegliere un nome.

Io prevederei anche delle API (semplici) del modulo qcfilter
mi pare che l'attuale qcfilter non soddisfi però tutte le funzionalità di dba_qcfilter

Non appena so dove mettere il codice, aggiungo possiamo aprire issue per bug e enhancement. Come funzionalità preesistenti, dovrebbero mancare solo le opzioni da linea di comando - ma questo possiamo vederlo nelle issue.

[dcesari]

Non so se può aiutare, io avevo creato prodsim per scopi un po' diversi, come un contenitore di roba sperimentale che usa libsim, (ma non necessariamente), in vista di una transizione ad una qualcosa di utile e pacchettizzabile (o separatamente o dentro libsim stessa). Se volete usarlo ad un fine diverso, tipo progetto per qualcosa che fa delle operazioni fisiche ben definite ed è già pacchettizzabile (magari dividendo in cartelle, sperimentale da non installare, funzionante da installare), non ho nulla in contrario.

[brancomat]

Non stiamo parlando di futuribile o pacchetti opzionali/sperimentali, stiamo parlando di server operativi che devo potenziare ad hoc e procedure operative a cui dobbiamo trovare workaround perché dba_qcfilter piglia un quantitativo di risorse eccessivo.
Visto che la soluzione di Emanuele è già pronta e le dipendenze aggiuntive minimali io sarei per integrarlo in libsim.

Se no faremo l'ennesimo pacchetto, ma mi pareva inutile complicazione

[dcesari]

Se è la soluzione più indolore allora mettiamo in libsim/bin abilitabile/disabilitabile da configure.

[pat1]

bho, a me parrebbe più facile fare un pacchetto solo python piuttosto che mischiare pacchetti con stili diversi:
se volete mi propongo per fare un repo github e un pacchetto con un modulo con distribuzione basata su distutils e con un rpm base che va su copr
Secondo me ci dovrebbe già andare altra roba da usare in mistral
propongo come nome dba_util e tutti i moduli e tools dovrebbero cominciare con dba (chi non lo sapesse dba è il prefisso standard di dballe)

[pat1]

@edigiacomo anche io preciso che le dipendenze di libsim da dballe sono opzionali e sono dipendenze dalle api f77 ferme da anni; in questo caso avremmo dipendenze non opzionali da API python; inoltre il problema non è tanto aggiungere una dipendenza a libsim ma il fatto che per installare un filtro che spero diventi di uso abbastanza generico si aggiungano tutte le dipendenze di libsim ...

[edigiacomo]

Per tagliare la testa al toro, ho creato il repository https://github.com/ARPA-SIMC/dba_qcfilter.

Aprirò poi issue per rimuovere/rinominare il dba_qcfilter di libsim.