Abbildung 1: Das in 01/07 veröffentlichte Originalskript dient als Messbasis, seine Laufzeit ist auf 100 Prozent normiert. Bei kleinen Dateien ist Dapfys Version schneller (179 Prozent), bei großen siegt Memoize im RAM (341 Prozent). Bei Memoize mit Disk-Cache ist (1) der erste Lauf und (2) der zweite Durchgang.

Verteilte Optimierung in der Praxis: Zwei Leser haben Vorschläge geschickt, die ein im Linux-Magazin veröffentlichtes Perl-Skript beschleunigen. Die Messung liefert teils überraschende Ergebnisse.

Leserbriefe freuen Redakteure selbst dann, wenn zum Beispiel Dapfy schreibt: “Die Idee, Mailadressen beim Seitenausliefern umzuschreiben, ist pfiffig! Die Umsetzung leider nicht” [2]. Nach dieser Einleitung gibt er detaillierte Hinweise, wie es besser geht – klasse! Er informiert, dass »shift« bei der Parameterübergabe unnötig Zeit kostet, wie die Regular Expression flotter wird und welche Taktik beim Auftrennen der Daten-Chunks geschickter ist.

Dapfy hatte in seiner Mail auch Linux-Magazin-Perl-Guru Michael Schilli auf CC gesetzt. Der reagierte prompt mit dem Hinweis [3] auf ein Perl-Modul: Memoize [4] merkt sich die Ergebnisse von Funktionen in einem Cache und spart ab dem zweiten Aufruf mit identischen Parametern die Berechnung. Tobias Eggendorfer, der Autor des Skripts und des dazu gehörenden Artikels zur Spam-Prävention [1], ging den Vorschlägen auf den Grund: Abbildung 1 zeigt die Beschleunigung je nach Optimierung und Dateigröße.

Abbildung 1: Das in 01/07 veröffentlichte Originalskript dient als Messbasis, seine Laufzeit ist auf 100 Prozent normiert. Bei kleinen Dateien ist Dapfys Version schneller (179 Prozent), bei großen siegt Memoize im RAM (341 Prozent). Bei Memoize mit Disk-Cache ist (1) der erste Lauf und (2) der zweite Durchgang.

Gemessen hat Tobias mit Apache-Bench »ab -n 1000 -c 10« auf einem Pentium Mobile (735 MHz, 512 MByte RAM) mit Fedora Core 2. Ohne Obfuscate-Skript brauchte der Server 1,1 Millisekunden für eine 271 Byte große Datei. Die 4,6-KByte-Datei dauert gleich lange. Erst bei 2,2 MByte steigt der Aufwand merklich auf 9,7 Millisekunden. Mit dem in [1] abgedruckten Skript kletterte der Zeitbedarf dagegen je nach Dateigröße von 1,7 über 3,2 auf 271,9 Millisekunden.

Verschlimmbessert

Dapfys Version ist bei kleinen Files tatsächlich schneller (179 Prozent). Aber die Überraschung: Schon bei mittelgroßen HTML-Dateien wird sie langsamer und schafft bei der 2,2-MByte-Datei nur noch ein Drittel der Performance! Die Redaktion vermutet, dass Perl dank der substituierenden Regular Expression »$buffer =~ s/([@w.-]+)z//;« intern mehr Daten kopieren muss als beim Match »$buffer =~ /(.*)(sS*)z/gs;« und den beiden anschließenden Zuweisungen im Originalskript.

Memoize im RAM bringt bei kleinen Dateien kaum Vorteile. Bei größeren Dokumenten ist es ordentlich schneller und katapultiert bei 2,2-MByte-Files das Resultat auf 341 Prozent. Tobias ergänzte noch einen Memoize-Aufruf mit Disk-Cache. Damit legte das Modul alle Parameter-Resultat-Paarungen auf Platte ab – es profitieren parallel laufende oder später gestartete Instanzen von früheren Berechnungen.

Wenig überraschend liegt die Kombination aus Dapfys Obfuscate-Variante und Memoize zwischen den beiden Einzeloptimierungen. Ein weiterer Versuch zeigt, dass auch das simple Ersetzen des Funktionsaufrufs durch direktes Schreiben in den Quelltext (Obfuscate inline) bei mittleren HTML-Dateien Zeit spart. Alle Varianten liegen auf [5] zum Download. Vielleicht melden sich ja weitere Leser mit anderen Optimierungsansätzen?

Copyright © 2002 Linux New Media AG