BenchmarkTimer - Kindprozess oder doch nicht?

[dingsda]

Hallo,
ich hab grad bischen mit dem BenchmarkTimer rumgespielt. dabei bin ich auf folgendes verhalten gestossen

Code: Alles auswählen

$t=Singleton::getInstance('APF\core\benchmark\BenchmarkTimer');
$t->start('process 1');
$t->start('process 2');
$t->stop('process 1');
sleep(5);
$t->stop('process 2');
echo $t->createReport();
 

Ausgabe ist ungefähr

Code: Alles auswählen

Root ----------------------5.3983209133 s
     process 1-------------0.0145349503 s
          process 2--------5.0129950047 s

process 2 ist eigentlich ein kindprozess von process 1 im benchmarkTimer. eigentlich müsste dieses daher auch vor process 1 beendet werden. der BenchmarkTimer hat kein problem damit, dass der prozess erst nach prozess 1 beendet wird. nur in der ausgabe sieht das nun echt komisch aus.

der grund für die frage ist eigentlich nur, ob das überhaupt ein gewünschtes verhalten ist. also macht es eurer meinung nach sinn, dass man so messen kann?
Ich will den Timer etwas erweitern. hab schon ein bischen was zusammengebaut, aber festgestellt, dass ne messung wie oben in meinem Timer nicht mehr möglich wäre. Müsste ich natürlich noch berücksichtigen, wenn sowas überhaupt gewünscht ist.

[dr.e.]

Hi,

was du aufzeigst ist grundsätzlich gewünschtes Verhalten. Effektiv sind alle Prozesse ineinander geschachtelt - mit Ausnahme des Root-Prozesses - und zeigen dir damit die verbrauchte Zeit in einem Zwiebelschalen-Modell an.

Dein Code-Beispiel ist zwar technisch korrekt, inhaltlich kommen überschneidende Messpunkte im Rendering-Modell des APF nicht vor. Ein Document::onParseTime() wird beispielsweise immer eine abgeschlossene Aktion innerhalb einer anderen sein (evtl. der selben) und eine Front-Controller-Action wird immer abgeschlossen sein - mit all seinen internen Abhängigkeiten - ehe eine andere abgearbeitet wird.

Aus diesem Grund erzeugst du unter "normalen" Bedingungen auch keine Darstellung wie du sie provoziert hast. Technisch kannst du das natürlich tun und die Implementierung lässt das auch zu. Sicher kannst du auch eine Sicherung einbauen um das zu verhindern, ich bin jedoch der Meinung, dass ein Framework nicht alles per Dekret verhindern sollte (open-close-principle).

Weitere Kommentare siehe Tracker-Eintrag.

[dingsda]

ich hatte jetzt auch nicht an ne sicherung gedacht um das zu verhindern. bei meiner implementierung hatte ich nur nicht dran gedacht, dass so eine messung vorkommen könnte. und wie du auch selbst sagst würde sie normal auch gar nicht vorkommen.

ich bin auch der meinung, dass ein framework seine anwender nicht gängeln sollte. aber wenn wir uns mal das ergebnis der messung anschauen, dann fällt auf, dass der benchmarktimer das überhaupt nicht richtig abbilden kann. denn hier verlässt es eigentlich das "zwiebelschalen-modell".

[dr.e.]

Das ist natürlich auch wieder war. Ich stelle mir dann die Frage, wie wir damit umgehen sollten. Einem Auto baust du ja auch keine Elektronik ein, die den Fahrer davon abhält mit 200km/h an die Mauer zu fahren... Vermutlich (heute) einfach, weil es unverhältnismäßig teuer sein würde. So sehe ich das auch fast mit dem BenchmarkTimer. Er erzeugt ja - wie du schon richtig gemessen hast - einen nicht zu verachtenden Overhead.