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](https://forum.selfhtml.org/self/2016/jan/21/php-serialize-unserialize-ineffizient/1659160#m1659160). > 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](http://handwerkzeugs.de/parsemultipart.html) 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

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 [https://forum.selfhtml.org/self/2016/jan/21/php-serialize-unserialize-ineffizient/1659160#m1659160](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](http://handwerkzeugs.de/parsemultipart.html) 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