[gelöst] Profiling: tmpfile_s benötigt ca. 90% der Zeit
-
Hallo zusammen,
gerade profile ich eine Funktion (VC2005, release, STL debugging aus, speed-optimiert, bla), die viele (grob 10.000) Dateien (jeweils so um die 30kB) einliest. Da sie den Krempel dann noch mit zlib im Speicher entpackt, wollte ich mal schaun, wo die Zeit so draufgeht. Laut very sleepy, verbringe ich die meiste Zeit in tmpfile_s, was irgendwo in MSVCR80 liegt. Der Callstack dazu ist allerdings leer. Läuft das in irgendeinem Thread vom OS (Windows 7, x64, Programm ist für 32bit kompiliert) und ist das das eigentliche Einlesen der Datei?
Vielleicht kennt einer von euch das Phänomen ja schon.
Ansonsten kann ich aber natürlich auch ein Minimalbeispiel nachliefern.Gruß
Dobi
-
Ich tippe eher darauf, dass die Info falsch ist.
Den Code zu tmpfile_s findest Du als Source Code in der VS Installation.Du hast wahrscheinlich nicht genügend PDB Dateien für alle Module.
-
Yeah, ich habs deshalb mal mit einer Debug-Version versucht, und schon sieht alles viel sinnvoller aus.
Vielen Dank.
-
Besser wäre PDB Files für die Release-Version erstellen zu lassen.
Es gibt IMO keinen guten Grund für die Release-Version keine erstellen zu lassen - obwohl das bei VS komischerweise Default ist (bzw. bei vielen Versionen war).Du willst ja schliesslich nicht dass die Debug Version möglichst schnell läuft, sondern die Release Version...
-
Jupp, für meine Projekte mach ich das auch immer. Alle Funktionen, die aus meinem Programm (und den libs) aufgerufen wurden, sahen im Profiler auch schön aus, aber der Kram, mit dem ich selbst dann nix mehr zu tun hatte, wurde halt falsch berechnet/dargestellt.
-
Nochwas...
tmpfile_s() erzeugt ein Temp-File.
K.a. wo dein Programm das macht. Setzt mal nen Breakpoint rein im Debug-Build, dann siehst du es.Wenn z.B. pro einzulesender Datei ein Tempfile angelegt wird, dann wundert mich nicht, dass da 90% der Zeit dabei draufgehen. IO ist halt langsam.
-
Nein, ich leg kein Tempfile an. Ich hol mir den Kram einfach aus nem ifstream. Mit Debugsymbolen für MSVCR80 (also in meiner Debug-Version) steht im Profiler auch gar nix mehr von tmpfile_s. Die Zeit geht da wie erwartet in ifstream::read, beim Entpacken und Parsen der Structs drauf, und so viel langsamer als die Release-Version ist es auch nicht, dass man jetzt den Verdacht haben müsste, dass die tmpfile_s-Zeit von vorher einfach nur untergeht. Bin also nun vollends zufrieden.
-
Gut
BTW: wie findest du "very sleepy" so allgemein? Ich hab' das Ding noch nicht ausprobiert, sieht aber ganz nett aus.
Weisst du wie das Ding seine Daten holt?Ich hatte nämlich mal das Teil von AMD probiert (CodeAnalyst oder wie das hiess), und das konnte mit Intel CPUs nur Timer-based Sampling, und zwar mit 1 Sample pro Millisekunde. Was IMO viel viel zu wenig ist um ordentlich profilen zu können.
-
Bisher finde ichs sehr gut. An Alternativen hab ich aber auch nur den CodeAnalyst (und den auch nur sehr kurz) ausprobiert. Für die Sachen, die ich mache, hat bisher immer dicke gereicht, was very sleepy kann.
Das Original-Sleepy sagt:
"Every 1ms or so, the profiler thread suspends the target thread, and pulls out the current instruction pointer register value from the thread context. These mem addresses are resolved into procedure names and line numbers using debug information. This allows line-level resolution, without making any changes to the target program. The only requirement is that the target program is compiled with (MS) debug information "Very Sleepy hat vermutlich an der eigentlichen Methode nichts geändert:
"The original version is a bit lacking in many areas, so I’ve been doing some work on it.
My version (“Very Sleepy”) has a boatload of improvements in, such as call-graph profiling, an improved UI, load-save, GCC support, and 64-bit support."Um vernünftige Ergebnisse zu bekommen, bau ich meist schnell ein Testprogramm mit ner Schleife um das zu testende drumherum, damit es 10 Sekunden oder länger laufen kann, und dann sind auch die Ergebnisse zuverlässig. Manchmal muss man halt ein wenig rumprobieren, um nicht zu sehr auf CPU-Cache-Effekte reinzufallen, geht aber normalerweise.
