Profiling & OOP

CM · Freitag 21. Oktober 2005, 22:14

Hoi,

Kennt jemand einen Weg Profiling und OOP zu verbinden? Mir fehlt gerade der Einstieg.
Das Problem: Mal angenommen ist gibt ein Modul mit (einer) Klasse(n). Wie kann ich quantifizieren welche Methoden der Klasse wirklich CPU-Zeit brauchen. Bietet das profile-Modul eine Möglichkeit? Wenn ja wie? (Ich möchte tunlichst nicht im Code des Moduls rumpfuschen

.) Gibt es andere Möglichkeiten, vielleicht ein externes "Speedtest"-Modul? Wie kann man das aufbauen? Gibt es Beispiele?
Die einzige Möglichkeit, die ich mir denken kann ist meine unittests dafür zu mißbrauchen. Ich habe ein sehr umfangreiches Testmodul für alles Mögliche. Jetzt könnte ich natürlich mit time.time() vor und nach jedem Test ein Profiling versuchen. Nachteile: Jede Funktion wird nur einmal aufgerufen und das reicht nicht, jede Funktion ist von dem unittest-Overhead überschattet und das Unittest-Modul würde recht unübersichtlich. Also keine sooo dolle Alternative ...

Kann mich wer auf die richtige Spur setzten?

Danke,
Christian

BlackJack · Freitag 21. Oktober 2005, 23:32

Was ist an der Kombination von Profiling und OOP so besonderes?

Wirklich sinnvoll ist IMHO nur das Profiling von echtem Programmcode und weniger das theoretische Testen wie sich eine Funktion bei 1000 Aufrufen verhält. Wenn die Funktion nicht 1000 mal in existierendem, realen Code ausgeführt wird, dann ist die gemessene Zeit ziemlich sinnfrei.

Leistungsmessungen machen im Allgemeinen nur in zwei Fällen Sinn: Man hat zwei Alternativen und will wissen welche schneller ist, oder man will den Flaschenhals in einem existierenden Programm finden.

Im ersten Fall würde ich repräsentative Eingabedaten verwenden und die beiden Alternativen ein paar tausend mal darauf loslassen und mit dem `timeit` Modul schauen was schneller ist. Das komplizierteste dabei ist meistens die geeigneten Testdaten zu finden oder zu generieren um ein möglichst realistisches Bild zu bekommen.

Im zweiten Fall kann man das Programm mit dem `profile` oder `hotshot` Modul auch wieder über typische Eingabedaten laufen lassen und sehen wo viel Zeit verbraucht wird, wo sich also Optimierungen am ehesten lohnen würden.

CM · Montag 24. Oktober 2005, 08:12

BlackJack hat geschrieben:Was ist an der Kombination von Profiling und OOP so besonderes?

Nichts, außer, daß es u. U. die Sache verkompliziert, da man etwas mehr zu Fuß machen muß. Aber mir ist jetzt aufgegangen, wie ich das rel. einfach erledigen kann: Den Unittest kopieren und umschreiben.

BlackJack hat geschrieben:Wirklich sinnvoll ist IMHO nur das Profiling von echtem Programmcode und weniger das theoretische Testen wie sich eine Funktion bei 1000 Aufrufen verhält. Wenn die Funktion nicht 1000 mal in existierendem, realen Code ausgeführt wird, dann ist die gemessene Zeit ziemlich sinnfrei.

Richtig: Ich habe ein Commanlinetoolset, daß schon ein ganzes Weilchen läuft, bevor es fertig ist - und die Funktionen werden schon sehr viele Male aufgerufen (einmal pro Teildatensatz).

BlackJack hat geschrieben:Leistungsmessungen machen im Allgemeinen nur in zwei Fällen Sinn: Man hat zwei Alternativen und will wissen welche schneller ist, oder man will den Flaschenhals in einem existierenden Programm finden.

Genau auf der Suche nach dem Flaschenhals bin ich ja. Kandidaten dafür habe ich schon - sicher bin ich mir nicht.

BlackJack hat geschrieben: Im zweiten Fall kann man das Programm mit dem `profile` oder `hotshot` Modul auch wieder über typische Eingabedaten laufen lassen und sehen wo viel Zeit verbraucht wird, wo sich also Optimierungen am ehesten lohnen würden.

Darauf wird es wohl hinauslaufen - ich habe verkannt, daß diese Dinge zu individuell sind, um schon fertige Beispiele einfach umstricken zu können. Dennoch Dank für Deine Anregungen.

Gruß,
Christian