2009-05-30T15:46:15 RPerl

Gibt es bei Perl eigentlich auch sowas aehnliches wie
www.phpbench.com ?

Die Seite www.phpbench.com halte ich teilweise für ziemlich nutzlos. Eine Programmierregel besagt das man nicht vorreilig Optimieren soll.

Zumal die Zeiten dort schon lächerlich sind. Bei einer Foreach schleife messen sie 620 mikrosekunden und für ihre lange version eine alte for schleife und vorher mit sizeof die elemente festlegen dauert 80 mikrosekunden.

Das hört sich erstmal viel an, aber beides ist immer noch unter einer Millisekunden und für einen Mensch nichtmal ansatzweise spürbar.

Wenn du 1000 leere foreach schleifen hintereinander machst dann hättest du mit der foreach version also insgesamt 620 millisekunden und bei der ausgedehnten version 81 millisekunden.

Das würde man zwar als Mensch merken (zumindest wenn das programm lediglich aus den beiden schleifen besteht und sonst nix weiter machen), allerdiengs wirst du nie hingehen und 1000 mal hintereinander arrays durchgehen und absolut nichts machen. Und das ist der knackpunkt. Das was du anstellst, und das sind ja meist irgendeine bearbeitung wird wohl den mammut anteil der Laufzeit ausmachen und nicht das durchlaufen der schleife.

Und wenn du bei jedem Schleifendurchlauf etwas machst und das bereits 10 millisekunden dauert, und jedes array 100 einträge hat. dann würde deine foreach version: 100,606 millisekunden brauchen und deine ausgedehnte for schleife 100,81 millisekunden. Die unterschiede sind also lächerlich gering.

Es mag dann zwar sein das eine foreach schleife auf dem papier 750% schneller ist als die lange version. Wenn das Programm aber nur 0.01% seiner CPU Zeit in einer schleife verbringt, hat es am ende keinerlei auswirkungen wenn du diesen Teil Optimierst.

Ansonsten schaut die Optimierung dann auch noch so aus das du fehleranfällig code schreibst. Ein Array durchzugehen und größe selber festlegen und die bedingung selber festlegen ist nunmal fehleranfällig und auch schlechter lesbar. Ansonsten muss du Grundsätzlich ja mehr schreiben für diese "extended" version. Die Vorteile die ein foreach also hat würde ich nicht aufgeben, zumal diese wohl sowieso nicht die performance lücke sein wird, sondern eher das was du in der schleife tust.

Daher halte ich diese Seite auch für PHP Entwickler für total sinnlos, und wenn man die Performance erhöhen möchte dann sollte man einen Profiler nutzen um die stellen zu suchen die am meisten Zeit beanspruchen und diese stellen Optimieren.

Und wenn man sie gefunden hat dann eben die stellen optimieren, ein besserer algorithmus, vielleicht ein caching? etc.

Alles andere ist Sinnlos.
Last edited: 2009-05-30 23:13:17 +0200 (CEST)

2009-05-30T18:21:07 RPerl

Die "schuldige" Funktion hab ich ja eigentlich schon:

Code (perl): (dl )

sub ip_add_num

Hi, nein das ist nicht die Schuldige Funktion. Ich habe folgenden Code geschrieben:



Und einmal Profiled. Das ergebnis ist allgemein gesagt das die meiste Zeit in "Math::BigInt" verschwendet wird.

43.6s ist die Zeit die der Sourcecode benötigt, und davon fallen schon 32.5 Sekunden in den Math::BigInt Namensraum. Also knapp 75% der Zeit wird dort verschwendet.

In Net::IP werden 10.8 sekunden Zeit verbraucht. Also knapp 24% der gesamten Zeit.

Wenn du Net::IP verbessern möchtest dann musst du folgende Subroutinen Optimieren:

Net::IP::ip_bincomp => ~4s
Net::IP::ip_bintoint => ~2s
Net::IP::ip_binadd => ~2s

Sinvoller wäre es aber Math::BigInt zu verbessern. Leider hat Perl anscheind kein gutes Modul womit man große Zahlen effizent bearbeiten kann. Zwar sind die Math::* Module Portable (da alles pure Perl) aber grotten langsam. Und sind hier auch der Punkt warum das ganze am meisten ausbremst. Man kann zwar auch GMP verwenden das eigentlich in C geschrieben ist, und man kann Math::BigInt sogar sagen das er dieses nutzen soll wenn es verfügbar ist.



Dann würde er "Math::BigInt::GMP" nutzen wenn verfügbar oder wenn nicht wieder zum Perl Only zurück fallen. Allerdiengs macht das nicht viel unterschied. 40.2s ausführungszeit anstatt 43.6s sekunden, und 29s in Math::BigInt anstatt 32.5 sekunden.

Wenn du zumindest von dem bisschen Profitieren möchtest dann musst du das ganze so laden. Und natürlich auch "Math::BigInt::GMP" installiert haben.



Ansonsten muss man das Ergebnis weiter durchschauen. Zwar wird knapp 4 sekunden in Net::IP::ip_bincomp verschwendet, allerdiengs nicht weil die sub so langsam ist (durchschnitt braucht diese nur 97 mikroskunden pro durchlauf) sondern weil die funktion so oft aufgerufen wird.

Alleine fast 40.000 mal aus Net::IP::ip_range_to_prefix heraus. Von daher stimmt die Liste der drei Funktionen oben eigentlich nicht. Aber eins steht fest, wenn du die engpässe finden möchtest musst du Profilen.

Ansonsten müsste man schauen ob überhaupt so viele aufrufe an Net::IP::ip_bincomp nötig sind, ob man es nicht vielleicht cachen kann. Oder ob vielleicht ein anderer Algorithmus nicht sinvoller wäre etc.

Zumindest steht fest, wenn du das ganze schneller haben willst müsste man
1) Eine schnelle Implementation haben womit man in Perl große Zahlen bearbeiten kann. (So eine Bibliothek ist mir nicht bekannt und habe danach schonmal vergeblich gesucht)

2) Erst dann schauen ob man Net::IP verbessern könnte. z.B. mehr ergebnisse cachen oder die anzahl der aufrufe an Math::BigInt verringern

3) Oder eben Net::IP umschreiben das es eine Bibliothek aus Punkt 1) benutzt

4) Andere Programmiersprache nutzen. Python ist hier z.B. nicht so Crap wie Perl.

Durch eine simple umstellung der Schleife wirst du jedenfalls absolut gar nichts erreichen.
Last edited: 2009-05-30 23:27:47 +0200 (CEST)