_heap_alloc_dbg_impl macht Debugausführung extrem langsam

Question

Hallo Leute, ich habe hier einen binären Baum (vom Kollegen in Source zur Verfügung gestellt)  der läuft im Release Mode 1a aber im DebugModus braucht er bei größeren Bäumen Minuten um sich neu auszutarieren, im Release dauert es 1-2 ms.

Wenn ich das Programm unterbreche befindet er ich immer in einer Routine in dbgheap.c.

Das ganze ist ein MFC Projekt (statisch gelinkt) und tritt in VS2008 wie VS2013 gleichermaßen auf. Kann man irgendwie verhindern das er die heap Funktion aus dbgheap benutzt? Ich habe schon ne ganze Menge an Makros und Afx* probiert, aber so richtig finde ich nix.

Bin für jeden Tipp dankbar.

Freudi

 

---

Freudi

Answer 1

Soweit ich weiss, sollte man beim Debuggen eines 'Debug-Builds' in Windows, zwei Dinge im Auge behalten:
Zum Einen den System-Heap-Manager:
Stichwort ntdll!RtlDebugAllocateHeap, _NO_DEBUG_HEAP Umgebungsvariable
http://ofekshilon.com/2014/09/20/accelerating-debug-runs-part-1-_no_debug_heap-2/
Zum Anderen, den 'Debug-Heap', der von der Microsoft C-runtime-library ausgeführt wird:
Stichwort: _heap_alloc_dbg_impl
Dieser wird beim Kompilieren festgelegt: Laufzeitbibliothek Multithreaded-Debug (/MTd) oder Multithreaded-Debug-DLL (/MDd).
https://software.intel.com/en-us/articles/using-the-microsoft-debug-heap-manager-with-memory-error-analysis-of-intel-parallel
Vielleicht reicht ja ein 'Release-Build' ohne 'Optimierung' zum Debuggen aus?
http://ofekshilon.com/2014/10/14/accelerating-debug-runs-part-2-_iterator_debug_level/

Mit freundlichen Gruessen

Answer 2

Danke für die Antwort.

Ich habe auch mal von /MTd auf /MT umgestellt, (die MFC ist statisch gelinkt) das hat komischerweise nix gebracht er geht immer noch durch _heap_alloc_dbg_impl, das hätte ich nicht erwartet.

Genau dasselbe mit _NO_DEBUG_HEAP=1 als Parameter bei Debuggen-Umgebung, er benutzt immer noch die Funktionen in dbgheap.c die das ganze extrem langsam machen. 

Auch "Vollständige Laufzeitüberprüfung" auf "Standard" macht keinen Unterschied.

Wenn ich mal viel Zeit habe werde ich mal alle Compilerschalter durcharbeiten, jetzt Debugge ich via OutputDebugMessage im Release Modus :-(

Freudi

---

Freudi

Answer 3

Du kannst doch auch so im Release mode debuggen. Erzeuge Debug Symbole und das war's.

Wieso meinst Du, dass man ein Release Programm nicht debuggen könnte?
Auch viele Variablen, die nicht komplett wegoptimiert wurden sind sichtbar.

Ansonsten lassen sich im Debug Modus nicht alle Debug Funktionalitäten ausschalten.

Lies mal die Doku zu _CrtSetDbgFlag

https://msdn.microsoft.com/de-de/library/5at7yxcs.aspx?f=255&MSPPError=-2147217396Setze auch

_CRTDBG_ALLOC_MEM_DF  auf OFF. _CrtSetDbgFlag(0) sollte fast alle Debug Einflüsse des Heaps beenden.

---

Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de

Answer 4

Hallo Martin

Die Dokus zu den Heapgeschichten die bislang hier erwähnt wurden habe ich schon durch, ich denk es passiert schon beim Linken, denn im DebugModus läuft er immer auf meine Brechpunkte in dbgheap.c das scheint man dynamisch mittels Flag's auch nicht beeinflussen zu können.

Ja ich kann auch im Relaase Modus Debuggen aber da geht z.B. "Bearbeiten und Fortfahren" und das ist bei dem Problem was ich bearbeiten soll echt unpraktisch. Wenn was nicht geht hole ich mir SourceCode zusammen und schreibe den während des Debuggens in die Quellen und es ist auch immer schwer eine bestimmte Situation herzustellen, wenn ich neu starte brauche ich immer 10-15 Minuten bis ich wieder an der Stelle bin wo ich aufgehört habe.

Ich werde trotzdem etwas als Antwort markieren obwohl ich eigentlich immer noch nicht weiß was dafür sorgt das die Routinen dbgheap.c durchlaufen/benutzt werden. Ich dachte es wäre ein simpler Compilerschalter :-(

Thomas

---

Freudi

Answer 5

Nein! Grundsätzlich wird immer ein gewisser Overhead in den Debug Bibliotheken erzeugt. Man kann auch einige Prüfungen ausschalten. Aber das Guards verwendet werden kann man nicht verhindern...Allerdings sollte das Prüfen der Verkettungen eigentlich nicht stattfinden, wenn bestimmte Flags ausgeschaltet werden.

---

Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de

Answer 6

Dann ist es vielleicht etwas was ich gar nicht abschalten kann, deswegen soll das jetzt auch wirklich der Abschlusssatz sein.

Es war halt bei dem durchprobieren in den letzten Tagen so das er beim Befehl des Neuaufbau des Baumes länger hängen blieb und wenn ich dann auf Unterbrechen geklickt habe befand er sich immer in dbgheap.c

Danke Martin

---

Freudi