Optimierung einer Methode (byte-Geraffel)

[miasma]

Hallo,

weiß jemand, wie man diese Methode: https://github.com/sirixdb/sirix/bl...in/java/org/sirix/node/SirixDeweyID.java#L507

optimieren kann, da die Serialisierung bei ca. 310_000_000 Knoten in einem Test ca. 18% der CPU-Zeit schluckt (mittels YourKit Profiler geschaut) und insgesamt der Import einer JSON Datei dadurch von ca. 4 Minuten auf ca. 6 Minuten sogar steigt?

DeweyIDs sind hierarchische Knoten-Labels der Form: 1.3.1.3, 1.3.1.5 ... usw., d.h. aufgrund der labels kann man bspw. gleich sagen, welcher Baum-Knoten in preorder bspw. vorher kommt, was die ancestor Knoten sind usw.:

http://wwwlgis.informatik.uni-kl.de/cms/fileadmin/users/mathis/documents/HHM_SBBD.pdf

Ich nutze auch schon Java 18. Vermutlich könnte man sogar irgendwas mit der Vector-API versuchen? Die Klasse hatte ich damals von BrackitDB übernommen, einem XML-Datenbanksystem und wollte das auch für JSON-Daten zumindest optional haben, da ich hier dann bspw. gleich effizient ermitteln kann, ob in einem Subbaum eines Knotens eine Änderung stattfand (zusammen mit Hashes über die gesamte Baumstruktur), die Änderungen gleich sortiert werden können, wie man sie bspw. in einem preorder-Durchlauf erhalten würde usw..

Beste Grüße
Johannes

 

[httpdigest]

Solche "Bit-level" Optimierungen wie diese Dewey ID Serialisierung lohnen sich heutzutage eigentlich nicht mehr, wenn das Ziel hoher Durchsatz ist, also die Verarbeitung möglichst vieler "Daten"/Knoten in einem festen Zeitintervall.
Das Problem hier ist, dass Festplatten heutzutage sehr viel größere Datenmengen sehr viel schneller aufeinmal lesen können, so dass sich Optimierungen wie "Ich spare hier ein paar Bits in der Serialisierung" aufgrund des nun vergleichsweise sehr viel höheren Rechnenaufwandes im Vergleich zum Durchsatz des Datenspeichers, nicht mehr lohnen.
In dieser Methode (und in den von ihr aufgerufenen anderen Methoden) befinden sich ja sehr viele Schleifen, viele Byte-Index-Berechnungen, Modulo-Arithmetik, sehr viele Branches (in Form von if-then-else aber auch switch-expressions), Bit-Shifts, Integer-Arithmetik, noch mehr Schleifen und noch mehr Branches.

Du wirst sehr viel höheren Durchsatz in der Verarbeitung der Daten erreichen, wenn du z.B. einfach eine "variable length integer" Serialisierung wie etwa die bei Googles Protocol Buffers verwendest, um die IDs zu serialisieren und zu deserialisieren, statt diesem wilden Bit-Packing, wie es im Paper beschrieben ist.

Jetzt kommt es natürlich darauf an, ob du den Serialisierungsmechanismus aufgrund von Kompatibilität einfach so ändern kannst, oder nicht.

 

[miasma]

Kann ich in jedem Fall ändern, da ich nicht weiss, ob überhaupt jemand das System schon einsetzt. Das ist allerdings was, wo ich mich bislang noch gar nicht rangetraut habe. Was natürlich schon sehr schön ist, dass ich die bisher auch sortieren kann und nur das erste byte array voll speichere und bei den darauffolgenden nur noch den Teil, der sich hinten unterscheidet.