Das deutsche Python-Forum

Hallo,

habe eher eine philosophische Frage zu hdf5 und Python. Ich lese aus hdf5 per h5py in eine 1D Python Liste und per tables aus Python Liste dann in andere hdf5. Das Programm tut das, was es soll. Den einfachen Code für diesen "hdf5" Teil des Programms findet man auf den Projektseiten von tables oder h5py.

Die 1D Listen sind ca. 1e06..1e08 lang, mit float. Ich lese Wert für Wert aus der hdf5 Datei bis zum Ende und danach schreibe dann wieder Wert für Wert in eine andere hdf5 Datei. Das dies nicht der effektivste Weg ist ..... verständlich, aber warum derart langsam und mit derart hoher CPU Last verbunden? Das dies effektiver per numpy & Co. geht ist mir bekannt. Ich will es einfach halten und benötige die letzten 20% Performance nicht. Komisch ist, dass der Ansatz über die hdf5 Dateien etwa um den Faktor "100" langsamer ist als per ASCII Dateiansatz. Die hdf5 Arbeit produziert hohe CPU Last (100% des Core) aber kaum Netzwerklast (ca. 10KiB/s), dauert halt ewig. Die hdf5 sind compress. Kann das die Ursache bei der inkrementellen, sequenziellen Abarbeitung sein? Wo könnte der Flaschenhalt sein?

Python 3.9 h5py 2.10.0-9 und tables 3.6.1-3.

Gruß und Dank Markus

@m__golbs: Du arbeitest halt grob umständlich, wenn Du etwas Wert für Wert liest. Deshalb gibt es ja numpy, um einfach mit Vektoren arbeiten zu können. Das bedeutet auch, dass der Code viel einfacher ist, nämlich genau 3 Zeilen.
Es wäre übrigens besser, einfach den Code hier zu posten, statt ihn umständlich zu beschreiben.

Hallo,

danke für die Antwort.

Deshalb gibt es ja numpy, um einfach mit Vektoren arbeiten zu können.

Da gibt es einige Voraussetzungen bei der Arbeit mit Vektoren, die ich hier nicht ohne weiteres erfüllen kann. Daher der primitive Ansatz.

Meine Frage geht eher in die Richtung, warum der gleiche Algorithmus mit ASCII Dateien um Größenordnungen schneller ist als mit binären hdf5 Dateien. Wenn das bei der Arbeit mit den hdf5 nur effektiv mit einem Vektor Ansatz ist, muss ich halt damit leben, oder das in Vektor umsetzen was überschaubar geht.

Gruß und Dank Markus

Zeig doch Deinen Code! Ohne kann man dazu nichts sagen.
hy5py hat als Abhängigkeit bereits numpy, das Argument, dass das »bei der Arbeit« nicht erlaubt sei, zieht also nicht.

@m__golbs: Ohne konkreten Code zu sehen kann man halt nur spekulieren was da falsch läuft. Ansonsten: messen wo die Zeit ganz konkret verbraucht wird, und dann dort schauen was dort passiert.

Was zum Beispiel nicht wirklich geht ist komprimierte Arrays Wert für Wert schreiben. So etwas läuft dann schnell auf komprimiertes Array laden, dekomprimieren, um einen Wert erweitern, komprimieren, komprimiertes Array wieder speichern hinaus. Und das eine Million mal für eine Million Werte. Statt das da *einmal* alle Werte komprimiert und geschrieben werden. Wenn so etwas tatsächlich bei Deinen Performance-Problemen dahinter steckt, dann wäre das kein „man könnte das schneller machen“, sondern eher ein „man sollte das nicht so unglaublich umständlich und langsam machen“.

Hallo,

Was zum Beispiel nicht wirklich geht ist komprimierte Arrays Wert für Wert schreiben.

Das klingt plausibel und könnte es erklären. Werde mal die Komprimierung weg lassen.

Gruß und Dank Markus