Wir haben eine große C++ - Anwendung, die wir manchmal als Debug-Build ausführen müssen, um Fehler zu untersuchen. Der Debug-Build ist viel langsamer als der Release-Build, so dass er fast unbrauchbar ist.Wie MSVC-Debug-Builds schneller ausgeführt werden
Welche Tricks sind verfügbar, um MSVC Debug Builds schneller ausführen zu lassen, ohne zu viel auf die Debugfähigkeit zu verzichten?
Verwenden Sie #pragma optimize("", off) an der Spitze der ausgewählten Dateien, die Sie bei der Veröffentlichung debuggen möchten. Dies ergibt eine bessere Stapelverfolgung/Variablenansicht.
funktioniert gut, wenn es nur ein paar Dateien ist, müssen Sie den Fehler jagen.
Dies ist genau der Trick, den wir später entdeckt haben und nun schon seit einiger Zeit anwenden. (Ich habe vergessen, wieder zu kommen und SO zu aktualisieren). Die korrekte Syntax ist '#pragma optimieren (" ", aus)', auf die später ein '#pragma optimize (" ", on)' folgen kann, um den Compiler wieder normal zu machen, wodurch dieser Trick verwendet werden kann einzelne Funktionen gleichzeitig. – pauldoo
Danke für den Hinweis auf den Fehler. Ich habe es aktualisiert. – Macke
Profil der App und sehen, was ti die Zeit nimmt. Sie sollten dann in der Lage sein zu sehen, welches Debugging abgestimmt werden muss.
Wie wird das gemacht? Und was hat das damit zu tun, Debug-Builds schneller zu machen? – Owl
Es gibt einige Unterschiede zwischen Debug-Builds und Release-Builds, die sowohl die Debug-Fähigkeit als auch die Geschwindigkeit beeinflussen. Die wichtigsten sind das _DEBUG/NDEBUG-Define, die Compiler-Optimierungen und das Erstellen von Debug-Informationen.
Sie können eine dritte Lösungskonfiguration erstellen und diese Einstellungen ausprobieren. Das Hinzufügen von Debuginformationen zu einem Releasebuild verringert beispielsweise die Leistung nicht wirklich, aber Sie erhalten bereits einen sinnvollen Stacktrace, sodass Sie wissen, in welcher Funktion Sie sich befinden. Nur die Zeileninformationen sind aufgrund der Compileroptimierungen nicht zuverlässig.
Wenn Sie zuverlässige Leitungsinformationen wünschen, fahren Sie fort und deaktivieren Sie Optimierungen. Dies verlangsamt die Ausführung etwas, aber dies ist immer noch schneller als das normale Debug, solange die Definition _DEBUG noch nicht gesetzt ist. Dann können Sie ziemlich gut debuggen, nur alles, was "#ifdef _DEBUG" oder ähnliches hat, wird nicht da sein (z. B. Aufrufe zur Bestätigung usw.).
hoffe, das hilft,
Jan
Warum wechseln Sie nicht nur auf Debug-Informationen in Ihrem Release-Konfiguration?
Debug-Info ist in Release bereits aktiviert. Das Problem ist, dass viele Variablen im Debugger wegen der aggressiven Optimierung nicht lesbar sind. – pauldoo
Welchen VS verwenden Sie? Wir sind kürzlich von VS.net zu VS2008 gewechselt und ich habe die gleiche Langsamkeit beim Debuggen auf einem High-End-Rechner bei> 500k LOC-Projekt erfahren. Es stellte sich heraus, Intellisense Basis wurde beschädigt und würde sich ständig aktualisieren, aber irgendwo stecken bleiben. Löschen der .NCB-Datei löste das Problem.
Verwenden Sie MFC?
Meiner Erfahrung nach ist die Hauptsache, die eine Debug-Version verlangsamen kann, die Klassenvalidierungsroutinen, die normalerweise in der Veröffentlichung deaktiviert sind. Wenn die Datenstruktur überhaupt baumartig ist, kann es dazu führen, dass Teilbäume hundertmal erneut validiert werden.
Egal, wenn es, sagen wir mal, 10 Mal langsamer ist als der Release Build, bedeutet das, dass es 1/10 seiner Zeit damit verbringt, das Notwendige zu tun, und 9/10 etwas anderes macht. Wenn Sie währenddessen auf den "Pause" -Knopf drücken und sich den Call-Stack ansehen, sind die Chancen bei 9/10, dass Sie genau sehen, was das Problem ist.
It's a quick & dirty, but effective way to find performance problems.
gedreht Wir Iterator Debuggen mit dem Präprozessorsymbole off:
_HAS_ITERATOR_DEBUGGING=0
_SCL_SECURE=0
Es half ein wenig, aber es war noch nicht so schnell, wie wir möchten. Außerdem haben wir unseren Debug-Build mehr Release-ähnlich gemacht, indem wir NDEBUG anstelle von _DEBUG definiert haben. Es gab ein paar andere Optionen, die wir auch geändert haben, aber ich erinnere mich nicht an sie.
Es ist bedauerlich, dass wir all dies tun mussten, aber unsere Anwendung hat eine gewisse Menge an Arbeit, die alle 50ms erledigt werden muss oder unbrauchbar ist.VS2008 out-of-the-box würde uns ~ 60ms Zeiten für das Debuggen und ~ 6ms Zeiten für die Freigabe geben. Mit den oben erwähnten Optimierungen konnten wir das Debuggen auf ~ 20ms runterladen, was zumindest brauchbar ist.
Lassen Sie es einfach flach laufen (d. H. Kontinuierlich, nicht zeitgesteuert). Das 10: 1-Debugging: Release-Verlangsamung, die Sie sehen, ist nur die Art von Sache, die mit dieser Technik wirklich leicht zu finden ist: http://stackoverflow.com/questions/375913/what-cani-i-use-to -profile-c-code-in-linux/378024 # 378024 –
... sogar bei 20: 6 Verlangsamung, das bedeutet 70% der Zeit ist verschwendet. Wenn Sie also 10 Samples nehmen, sehen Sie den Grund auf dem Stack auf 7 +/- 1.45 Samples, und der Stack wird Ihnen sagen, warum es das tut, und es wird ein schlechter Grund sein, dass Sie einen Workaround finden können . –
Ich habe tatsächlich einen Profiler darauf ausgeführt. Das Problem wurde auf viele Methoden verteilt und es sah so aus, als würden die Header der Funktion die ganze Zeit aufessen, nicht der Körper. Ich kam zu dem Schluss, dass dies auf zusätzliche Überprüfungen zurückzuführen war, die Visual Studio im Debug-Modus machte. – MrSlippers
Erstellen Sie eine ReleaseWithSymbols Konfiguration, die aktiviert NDEBUG und hat keine Optimierungen definiert. Dadurch erhalten Sie eine bessere Leistung, während Sie genaue Symbole für das Debuggen beibehalten.
warum ist dies ein Community Wiki? – Aamir
Mir wurde in der Vergangenheit gesagt, dass ich alle Fragen "Community Wiki" machen soll. Ich weiß nicht wirklich was die Option tut. – pauldoo
............ lol – demoncodemonkey