Hallo zusammen,
wie würdet Ihr damit umgehen wenn Ihr einen Anwendungsentwickler dabei beobachtet würdet, wie er beim debuggen von Performanceproblemen einer Anwendung z.B. die Finger zum zählen nimmt, (oder im schnellen Tempo mündlich zählt) und diese Zählergebnisse als in steingemeißelte Sekunden begreifen möchte, anstatt die vom .NET Framework integrierten Möglichkeiten zu benutzen um tatsächliche Zeitspannen zu ermitteln und zu protokollieren? Oder macht Ihr das hin und wieder auch - wenn ja, warum?
Kennt jemand gute Online-Artikel über Zeitmessung, Zeitgefühl, Wahrnehmung von Zeit?
-yellow
Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).
Mein Blog: Yellow's Blog auf sqlgut.de
Das kommt auf die Situation an. Wenn ich eine nur mal grob sehen will, wie das Zeitverhalten einer implementierten Komponente ist, schau ich auch mal auf die Windows Uhr.
Muss ich aber Fehlertickets im Bereich Perfomance analysieren/beheben oder Aussagen "nach oben" an den Technischen Chefdesigner, NFA-Architekten oder Projektleiter weitergeben, dann setze ich auch einen Profiler wie JProfiler (gibt wahrscheinlich Pendants für .NET) ein. Muss ich Aussagen zur Performance des Gesamtsystems abgeben, dann kommen schon eher Tools wie Silk Performer und co. zum Einsatz.
Ich habe es während meiner Ausbildungszeit einmal gemacht...
Dabei ging es um den Vergleich zweier Methodiken zur Änderung von Daten in einer Datenbank.
Man hat schon deutlich den Unterschied subjektiv wahrnehmen können, trotzdem gabs vom Ausbilder "eins aufn Deckel".
Seither nutz ich zum Messen der "Geschwindigkeit" einzelner Methoden immer die Stopwatch-Klasse von .Net her ^^
Was die Wahrnehmung der Zeit angeht sollte man IMHO eh vorsichtig sein mit seinen Aussagen.
Wenn man zum x-ten mal ein und dieselbe Methode "misst" und man langsam gereizt ist könnte man dazu neigen schneller zu zählen... andersherum könnte einen die ewige Messerei aber auch derart langweilen, dass man beim Zählen fasst einschläft oder zumindest um einiges langsamer zählt.
Auch ist es schnell mal passiert, dass man irgendwie abgelenkt wird (z.B. von einem Kollegen, dem Vorgesetzten o.Ä.)... und dann war Alles für die Katz und man darf nochma von Vorne anfangen mit der Zeitmessung.
Wie würde ich damit umgehen, wenn ich einen Anwendungsentwickler dabei beobachten würde?
"Aber sonst haste Nix zu tun, oder?" 😃
so far
Karill Endusa
Dem Kollegen bei dem ich sowas beobachte würde ich wohl entweder geringe Motivation oder Kompetenz(wahlweise beides) unterstellen.
Ich beziehe mich dabei besonders auf "debuggen von Performanceproblemen".
Es existieren bereits also konkrete Probleme, wir reden also nicht mehr von einer Art inneren Nachkontrolle.
Konkrete Messroutinen und bestenfalls Profiler sind hier in jedem Fall notwendig um zu sehen wo der Flaschenhals genau sitzt.
Artikel dazu kenne ich nicht aber eine kleine Anekdote fällt mir ein das mal ein Kunde Feedback gab das dass System ja jetzt viel schneller läuft, eigentlich lief aber nur die Progressbar Animation schneller....
Also generell würde ich nicht mitzählen, da ich generell immer Log Meldungen ausgebe (werden dann in einer Release Version mit Preprocessor entfernt - teilweise). Und anhand der Zeitstempel im Log sehe ich schon mal grob ob wo Zeit liegen bleibt. (natürlich sind hier die Latenzen inbegriffen)
Sobald es dann um Millisekunden geht, kommt man eigentlich um einen Profiler nicht mehr rum ..
In der Arbeit haben wir für unser Framework einen eigenen "Timelogger" geschrieben, wo man die Zeiten hierarchisch loggen kann.