Binary safe alternative to serialize

[hotti]

Hi,

da ich ab und zu mal reine Bytesequenzen in Array's und persistent speichern muss, habe ich eine Alternative zu serialize/unserialize entwickelt (binaray safe), siehe Link.

Wer Lust und Laune hat, kann das mal testen. Am Algorithmus habe ich ein paar Tage gefeilt, evntl. geht der auch noch zu Verbessern. Ansonsten isses pure PHP ;)

Schönen Sonntag,
im Zeichen des Wassermann,
Horst

[dedlfix]

Tach!

da ich ab und zu mal reine Bytesequenzen in Array's und persistent speichern muss, habe ich eine Alternative zu serialize/unserialize entwickelt (binaray safe), siehe Link.

Das klingt ja so, als ob serialize()/unserialze() nicht binärsicher wäre. Das wäre aber nicht der Fall.

Zudem ist serialize()/unserialize() typsicher und man bekommt nicht alles als String zurück. Selbst mit Objekten und (Selbst-)Referenzen kommt serialize()/unserialize() problemlos klar. Und da Objekte mitunter nicht einfach zu ent/serialisieren sind, gibt es sogar Vorkehrungen mit denen man zu Fuß unterstützen kann: das Interface Serialize und die magischen Methoden __sleep()/__wakeup().

Fazit: serialize()/unserialize() kann mehr - und ohne dass Datenmüll im /tmp-Verzeichnis zurückbleibt.

dedlfix.

[ChrisB]

Fazit:

Mal wieder ein typischer Fall nach dem beliebten Drei-Stufen-Muster:

a) Hotti versteht eine gegebene Funktionalität nicht, oder hat Probleme mit ihr weil er sie nicht korrekt angewendet hat.
b) Hotti beschließt, eigene Lösung zu entwickeln.
c) Hottis eigene Lösung hinkt der bereits gegebenen Implementation technisch/fachlich/von der zu erwartenden Performance her/sonstwie mehr oder weniger weit (üblicherweise: mehr) hinterher.

MfG ChrisB

[M.]

Sag mal, kann es sein, dass du verdammt viel Langeweile hast?

[hotti]

Sag mal, kann es sein, dass du verdammt viel Langeweile hast?

Wenn ich Langeweile hätte, würde ich was Anderes machen, Holzhacken oder sowas.

Im Übrigen versagt PHP::serialize bei Array's mit vielen Einträgen (> 20T), mein Algorithmus hingegen, läuft durch ;)

Schönen Tag noch,
Horst

[M.]

Im Übrigen versagt PHP::serialize bei Array's mit vielen Einträgen (> 20T), mein Algorithmus hingegen, läuft durch ;)

Wie äussert sich das Versagen denn? Welchen Inhalt haben diese Arrays? Macht ja nen Unterschied ob ein Eintrag ein Byte lang ist oder 100MB

Wenn du mit solchen Arrays arbeitest, hast du ein grundsätzliches Strukturproblem. Das spiegelt aber so ziemlich alles wider, was du so bastelst.

Leider hast du letztes mal auf meine Frage nicht geantwortet: Wieso programmierst du keine eigene Programmiersprache? Das Rad neu zu erfinden, es aber erstmal oval zu bauen, scheint dein Ding zu sein.

[MudGuard]

Hi,

Im Übrigen versagt PHP::serialize bei Array's mit vielen Einträgen (> 20T)

Wow - 20T Einträge, also 20000000000000 Einträge? Da erstaunt mich, daß das überhaupt von PHP verwaltet werden kann ...

cu,
Andreas

[bubble]

Im Übrigen versagt PHP::serialize bei Array's mit vielen Einträgen (> 20T)

Wow - 20T Einträge, also 20000000000000 Einträge? Da erstaunt mich, daß das überhaupt von PHP verwaltet werden kann ...

Also erst dachte ich 20000 (T=Tausend) sind gemeint, das ging aber ohne Probleme (zumindest CLI, Webserver würden wohl je nach Daten an ihr Speicherlimit kommen).

Dann hab ich mal versucht mich an 20000000000000 anzunähern.

$t1=time();$a=Array();for($j=0;$j<10000000;$j++){$a[]='c';}$t2=time();var_dump(strlen(serialize($a)));$t3=time();$a=Array();echo $t2-$t1,"s ", $t3-$t2,"s ",$t3-$t1,"s\n";  
int(178888903)  
31s 21s 52s

Da meine VM nur 2GB bekommen hat, fängt sie bei mir bei mehr an zu swappen und das hab ich dann nicht mehr probiert. :'D

Allerdings zeigt sich schon hier, dass das Serialisieren schneller als das Erzeugen ist, also wird wahrscheinlich eher das Speicherlimit versagen als alles andere.

Beim groben überfliegen vom Code vermute ich, dass die einzelnen Segmente sofort geschrieben werden und nicht im Arbeitsspeicher gehalten werden, was eventuell des Rätsels Lösung ist.

MfG
bubble