2013-06-14T21:32:41 rosti

In c ist IO um ein Vielfaches schneller als in Perl. Das ergibt ein Benchmark. Das wissen wir schon.

Wissen wir das? Welcher Benchmark? Wenn etwas wirklich IO-limitiert ist, warum soll das dann in Perl um ein Vielfaches langsamer sein - Perl ruft doch intern dieselben Funktionen zum Lesen auf wie C.

2013-06-14T21:32:41 rosti

warum es in der Datei redundante Daten gibt: Beim Einlesen der Bytes baut sich der Hash of Hashes sozusagen wie von selbst wieder zusammen.

Oh, tolles Argument. Bei anderen Algorithmen, die auf redundante Daten verzichten, baut sich der HoH auch wie von selbst wieder zusammen.

2013-06-14T21:32:41 rosti

Zum Vergleich ein anderer Algorithmus, den ich vor ein paar Jahren entwickelt habe: Hierbei wird for each Entity erst die Anzahl der Attribute ermittelt und dann als Key-Value-Pair geschrieben. Das erfordert natürlich mehr CPU im Serialize- bzw. Deserialize-Prozess, einen weiteren Schleifenkörper und mehr IO (diesen anderen Algorithmus könnt Ihr in der Foo 3/2011 nachlesen, danke René, http://rolfrost.de/proglog.html?d=20110404 ).

Du reißt in dem Artikel(*) nur an (mit Bullet Points, ohne Code), wie du einen HoH serialisieren würdest - und ich hätte da vermutlich etwas Rekursives gebaut, sodass man auch tiefer verschachtelte Strukturen serialisieren könnte. Trotzdem verstehe ich nicht, warum man mehr IO haben sollte, wenn man redundante Daten vermeidet, die Datei also kleiner ist.

Und warum soll das mehr CPU verbrauchen? "Natürlich" ist das überhaupt nicht.

2013-06-14T21:32:41 rosti

Anwendungsfälle für EAV kennt jeder Programmierer.

Wenn du willst, dass jemand dein Modul ernsthaft benutzt, dann musst du, und das wurde auch schon mehrfach geschrieben, in der Dokumentation deutlich machen:

• wofür exakt dein Modul gut ist
• was die Ziele bei der Entwicklung waren - dies ist hier insofern wichtig, als es ja schon eine Menge anderer Serialisierer gibt und so somit deutlich herausstellen solltest, wie es sich davon abhebt
• und wo die Einschränkungen liegen
• ... und ein paar Tests wären gut

(*): ob length() byte- oder zeichenorientiert arbeitet, hängt nicht an use utf8 - es ist ganz einfach: es arbeitet IMMER zeichenorientiert. utf8 stellt ein, dass Strings im Quelltext utf8-kodiert sind. Somit ist deine Erklärung dort falsch.
Last edited: 2013-06-15 10:07:26 +0200 (CEST)