PHP serialize, unserialize ineffizient
1 
dedlfix
0 1 dedlfix
0 
Camping_RIDER
0 0 Camping_RIDER
1
PHP serialize, unserialize ineffizient
Das Benchmark zeigt Unterschiede in Größenordnungn im Vergleich mit Perls freeze/thaw und eigenen Entwicklungen. Kommt das bei Euch zum Breiteneinsatz? Dass XML- und JSON-Serializer auch in Perl lahme Enten sind, muss ich wohl nicht weiter erwähnen.
-
Tach!
Das Benchmark zeigt Unterschiede in Größenordnungn im Vergleich mit Perls freeze/thaw und eigenen Entwicklungen. Kommt das bei Euch zum Breiteneinsatz? Dass XML- und JSON-Serializer auch in Perl lahme Enten sind, muss ich wohl nicht weiter erwähnen.
Beeindruckende Zahlen, die so ein Benchmak liefert, nicht? Aber in der Praxis ist das üblicherweise völlig belanglos, weil die zwei, drei Vorkommen im Script im Grundrauschen untergehen - falls man das überhaupt für die Lösung der Aufgabenstellung braucht.
dedlfix.
-
Ich hab mal in einer Firma gearbeitet, die haben Shops programmiert. Und die haben sich gewundert, dass ihre Shops immer langsamer wurden. Kunde haben sich beschwert und bei einem Kunden lief der Shop gleich gar nicht mehr.
Als Ursache habe ich ermittelt, dass sämtliche Custom-Configs als JSON in ungezählten und immer größer werdenden Dateien persistent gehalten wurden (weil der CHef-Programmierer JSON so toll fand). Ein Ersatz der bisherigen Module durch XS-Pendanten auf mein Anraten brachte zumindest in den meisten Fällen vorübergehend Abhelfe.
-
Tach!
Ich hab mal in einer Firma gearbeitet, die haben Shops programmiert. Und die haben sich gewundert, dass ihre Shops immer langsamer wurden. [...] Als Ursache habe ich ermittelt, [...] (weil der CHef-Programmierer JSON so toll fand) [...]
Ja, das gibt es immer wieder, dass man sich in eine Technik verliebt und sie dann zu allen passenden und unpassenden Gelegenheiten einzusetzen oder zu propagieren versucht. Das diskreditiert aber üblicherweise nicht die Technik an sich.
dedlfix.
-
Die heutige Entwicklergeneration ist dadurch gekennzeichnet, dass keiner von denen Verantwortung übernimmt. So habe ich in meinen letzten Berufsjahren nicht einen Entwickler kennenglernt, der auch nur ansatzweise mal bereit gewesen wäre, seine eigenen Werklein kritisch zu betrachten.
Gepaart mit einem grottenschlechten Führungsstil wird Teamarbeit bereits im Keim erstickt. Die Kollegen arbeiten nicht miteinander sondern gegeneinander und das Mobben wird zum Programm. Daraus erwächst die Bestrebung, ständig den Weg des geringsten Widerstandes zu gehen und die eigentliche Motivation geht zum Teufel.
Schöne Grüße ;)
-
-
Aloha ;)
mal schnell off-topic...
Als Ursache habe ich ermittelt, dass sämtliche Custom-Configs als JSON in ungezählten und immer größer werdenden Dateien persistent gehalten wurden (weil der CHef-Programmierer JSON so toll fand). Ein Ersatz der bisherigen Module durch XS-Pendanten auf mein Anraten brachte zumindest in den meisten Fällen vorübergehend Abhelfe.
JSON ist mir ein Begriff, aber wat isn XS? Sei so gut und wirf mir mal nen Knochen in die richtige Richtung, per Google werde ich auf die Schnelle nicht fündig.
Grüße,
RIDER
-
Hallo Camping_RIDER,
JSON ist mir ein Begriff, aber wat isn XS? Sei so gut und wirf mir mal nen Knochen in die richtige Richtung, per Google werde ich auf die Schnelle nicht fündig.
http://perldoc.perl.org/perlxs.html
LG,
CK-
Aloha ;)
JSON ist mir ein Begriff, aber wat isn XS? Sei so gut und wirf mir mal nen Knochen in die richtige Richtung, per Google werde ich auf die Schnelle nicht fündig.
muchas gracias
Ist das weit verbreitet oder mehr was, was vor allem in perl und sonst nirgends vorkommt?
Grüße,
RIDER
-
Hallo Camping_RIDER,
Ist das weit verbreitet oder mehr was, was vor allem in perl und sonst nirgends vorkommt?
Perl-XS ist natürlich Perl-spezifisch. Jede Sprache hat ihr eigenes Interface, um C-Bibliotheken oder C-Module einzubinden.
LG,
CK-
Aloha ;)
Ist das weit verbreitet oder mehr was, was vor allem in perl und sonst nirgends vorkommt?
Perl-XS ist natürlich Perl-spezifisch. Jede Sprache hat ihr eigenes Interface, um C-Bibliotheken oder C-Module einzubinden.
Okay, dann habe ich nur den ursprünglichen Zusammenhang mit JSON falsch verstanden.
Grüße,
RIDER
-
-
-
-
-
-
-
Der Algorithmus, in PHP für die Funktionen serialize(), unserialize() zum Einsatz kommend, ist für diesen Test in Perl implementiert.
Verglichen mit PHPs nativer Implementierung in C sind alle von dir getesteten Algorithmen erliegend langsam. Bei Benchmarks muss man extrem vorsichtig sein, welche Rückschlüsse man ziehen kann und welche nicht. Deine Perl-Implementierung ist jedenfalls nicht geeignet um Rückschlüsse auf PHP zu ziehen. PHP ist beim benchmarksgame übrigens fast überall schneller als Perl.
Bei http://phpperf.com/ bringt es
serialize($this->object)auf etwa 322164 Operationen/Sekunde.Getestet auf diesem Setup:
CPU: Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz (Quad core)
RAM: 4Gb
OS: Ubuntu 12.04 Desktop Edition
PHP: 5.3.10-1ubuntu3.6-
Tach,
Deine Perl-Implementierung ist jedenfalls nicht geeignet um Rückschlüsse auf PHP zu ziehen.
es ist ja nicht seine sondern PHP::Serialization, da ist allerdings nicht beschrieben, ob überhaupt der selbe Algorithmus wie in PHP genutzt wird, nur dass das Ergebnis das selbe ist.
mfg
Woodfighter-
Tach,
es ist ja nicht seine sondern PHP::Serialization, da ist allerdings nicht beschrieben, ob überhaupt der selbe Algorithmus wie in PHP genutzt wird, nur dass das Ergebnis das selbe ist.
dass seine Algorithmen die vermutlich in C implementierte Funktion pack nutzen und PHP::Serialization die equivalente Sache in Perl implementiert, macht den Apfel-Birnen-Vergleich noch deutlicher.
mfg
Woodfighter-
Ich vergleiche Algorithmen, die auf das Ergebnis ausgerichtet sind. Es gibt einen wesentlichen Unterschied zwischen einer Strukturierung mit Längenangaben oder mit textlichen Mitteln.
Genau dieser Unterschied spiegelt sich im Benchmark wieder. Fürn JSON -String sieht das auch nicht viel besser aus, es bleiben Unterschiede in Gößenordnungen, meinen Artikel habe ich ergänzt.
Aber wahrscheinlich haben PHP-Programmierer die besseren Algorithmen ;)
-
Tach,
Ich vergleiche Algorithmen, die auf das Ergebnis ausgerichtet sind.
schön, dass du wiedermal deine nicht vorhandene Kritikfähigkeit zeigst. Wenn einem immer nur Geisterfahrer entgegenkommen, sollte man überprüfen, ob man selber in die richtige Richtung fährt.
Es gibt einen wesentlichen Unterschied zwischen einer Strukturierung mit Längenangaben oder mit textlichen Mitteln.
Genau dieser Unterschied spiegelt sich im Benchmark wieder.
Nein, das könnten sie nur, wenn du die anderen Einflüsse ausschließen könntest.
Aber wahrscheinlich haben PHP-Programmierer die besseren Algorithmen ;)
Obwohl ich nicht viel von PHP halte, gehe ich davon aus, dass die Entwickler von PHP sich mehr dabei gedacht haben als du bei deinem „Benchmark“.
mfg
Woodfighter-
Genau dieser Unterschied spiegelt sich im Benchmark wieder.
Nein, das könnten sie nur, wenn du die anderen Einflüsse ausschließen könntest.
Die sind ausgeschlossen, alles ist pure Perl außer der in C implementierte Algorithmus für Storable::freeze/thaw (Trotzdem ist Storable langsamer als mein eigener Algorithmus).
Und die von Dir erwähnte pack()-Funktion implementiert NICHT den Serialize-Algorithmus sondern dient lediglich dazu, die Längenangaben in Bytes zu kodieren (Integer als Big Endian).
Eine mit textlichen Mitteln vorgenommene Serialisierung ist i.d.R. ineffizient. Darum geht es, das zeigt der Benchmark und genau das ist schon seit Jahren meine Rede.
Das wohl dämlichste Beispiel für einen Serializer ist FormData Bemerkenswert wie lange sich so ein Schrott hält und dann auch noch in Javascript implementiert wird.
Warum FormData ineffizient ist, hab ich hier im Forum auch schon zur Genüge erklärt.
-
Tach,
Genau dieser Unterschied spiegelt sich im Benchmark wieder.
Nein, das könnten sie nur, wenn du die anderen Einflüsse ausschließen könntest.
Die sind ausgeschlossen,
nein, du hast immer noch nicht dargelegt, dass PHP::Serialization den selben Algorithmus wie die PHP-Implementierung nutzt oder ob es, weil es vielleicht mehr kann als deine Algorithmen (wo ich mir relativ sicher bin, da deine Algorithmen nur Hashes serialisieren können, soweit ich das sehe), aufwendiger ist.
alles ist pure Perl
Ja, aber PHP implementiert serialize nicht in Perl, was soll also dieser Vergleich zeigen?
außer der in C implementierte Algorithmus für Storable::freeze/thaw (Trotzdem ist Storable langsamer als mein eigener Algorithmus).
Auch der kann mehr als deine Funktionen.
Und die von Dir erwähnte pack()-Funktion implementiert NICHT den Serialize-Algorithmus
Das habe ich auch nicht behauptet.
sondern dient lediglich dazu, die Längenangaben in Bytes zu kodieren (Integer als Big Endian).
Das habe ich allerdings inzwischen auch gesehen.
Eine mit textlichen Mitteln vorgenommene Serialisierung ist i.d.R. ineffizient.
Warum das i.A. irrelevant ist, hat dedlfix schon beantwortet.
Darum geht es, das zeigt der Benchmark und genau das ist schon seit Jahren meine Rede.
Dein Benchmark zeigt im Moment, dass Algorithmen, die weniger können als andere, in einem Spezialfall schneller sind als solche, die mehr können. Das ist keine Überraschung.
Das wohl dämlichste Beispiel für einen Serializer ist FormData Bemerkenswert wie lange sich so ein Schrott hält und dann auch noch in Javascript implementiert wird.
Wenn du einen sinnvolleren Vorschlag hast, der das selbe erreicht, kannst du dich gerne an die WhatWG wenden, die werden dir dann erklären, warum du irrst.
Warum FormData ineffizient ist, hab ich hier im Forum auch schon zur Genüge erklärt.
Nein, du hast wie üblich gebrabbelt, Dinge falsch verstanden und bist auf Argumente nicht eingegangen, falls du https://forum.selfhtml.org/self/2015/nov/1/multipart-strich-form-data/1653480#m1653480 und https://forum.selfhtml.org/self/2016/jan/7/formdata-in-ajax-response/1658350#m1658350 meinst.
mfg
Woodfighter
-
-
-
-
-
-
Moin!
Bei http://phpperf.com/ bringt es
serialize($this->object)auf etwa 322164 Operationen/Sekunde.....
PHP: 5.3.10-1ubuntu3.6
Dann dürfte es mit PHP7 die 2 Millionen knacken.
Jörg Reinholz
-