2009-06-24 12 views
9

Mamy dużą aplikację C++, która czasami musimy uruchomić jako kompilację debugowania, aby zbadać błędy. Konstrukcja debugowania jest znacznie wolniejsza niż kompilacja wydania, do tego stopnia, że ​​prawie nie nadaje się do użytku.Jak sprawić, by kompilacje debugowania MSVC działały szybciej?

Jakie sztuczki są dostępne do wykonywania kompilacji MSVC Debugowania, które działają szybciej bez zbytniego poświęcania na debugowanie?

+0

Dlaczego to jest wiki społeczności? – Aamir

+0

W przeszłości mówiono mi, że wszystkie pytania są "wiki społecznościowe". Naprawdę nie wiem, co robi ta opcja. – pauldoo

+0

............ lol – demoncodemonkey

Odpowiedz

11

Użyj #pragma optimize("", off) u góry wybranych plików, które chcesz debugować w wydaniu. Daje to lepszy widok śledzenia stosu/zmiennej.

Działa dobrze, jeśli jest to tylko kilka plików, których potrzebujesz do wypróbowania błędu.

+0

To jest dokładnie ta sztuczka, którą później odkryliśmy i używamy od jakiegoś czasu. (Zapomniałem wrócić i zaktualizować SO). Poprawna składnia to '#pragma optimize (" ", off)', po której może nastąpić '#pragma optimize (" ", on)' aby przywrócić kompilator do normalnego stanu, dzięki czemu ta sztuczka może być użyta na pojedyncze funkcje na raz. – pauldoo

+0

Dzięki za wskazanie błędu. Zaktualizowałem to. – Macke

3

profil aplikacji i zobacz, co ti na czas. powinieneś wtedy zobaczyć, które debugowanie powinno zostać dostrojone.

+0

Jak to się robi? Co to ma wspólnego z budowaniem wersji debugowania szybciej? – Owl

1

Istnieje kilka różnic między kompilacjami debugowania i kompilacjami wydań, które mają wpływ zarówno na debugowalność, jak i szybkość. Najważniejsze są definicje _DEBUG/NDEBUG, optymalizacje kompilatora i tworzenie informacji debugowania.

Możesz utworzyć trzecią konfigurację rozwiązania i bawić się z tymi ustawieniami. Na przykład dodanie informacji debugowania do kompilacji wydania naprawdę nie obniża wydajności, ale już dostajesz rozsądny ślad stosu, dzięki czemu wiesz, która funkcja jest włączona. Tylko informacje o linii nie są niezawodne z powodu optymalizacji kompilatora.

Jeśli chcesz uzyskać wiarygodne informacje o linii, włącz i wyłącz optymalizacje. Spowoduje to spowolnienie wykonywania, ale nadal będzie ono szybsze niż zwykłe debugowanie, o ile nie zdefiniowano jeszcze definicji _DEBUG. Wtedy możesz zrobić całkiem dobre debugowanie, nie będzie tam tylko wszystkiego, co ma "#ifdef _DEBUG" lub podobne otoczenie (np. Wywołania, by potwierdzić itp.).

Nadzieja to pomaga,

Jan

4

Dlaczego nie można po prostu włączyć informacje debugowania w konfiguracji wersji?

+2

Informacje o debugowaniu są już włączone w wydaniu. Problem polega na tym, że wiele zmiennych jest nieczytelnych w debugerze z powodu agresywnej optymalizacji. – pauldoo

0

Z jakiego VS korzystasz? Niedawno przeprowadziliśmy się z VS.net do VS2008 i doświadczyłem tej samej powolności podczas debugowania na maszynie wysokiej klasy w projekcie> 500k LOC. Okazało się, baza Intellisense uległa uszkodzeniu i ciągle się aktualizowała, ale gdzieś utknęła. Usunięcie pliku .ncb rozwiązało problem.

1

Czy używasz MFC?

Z mojego doświadczenia wynika, że ​​główną rzeczą, która może sprawić, że wersja debugowania jest wolna, są procedury sprawdzania poprawności klas, które zazwyczaj są wyłączone w wersji. Jeśli struktura danych jest w całości drzewiasta, może skończyć się ponowną weryfikacją poddrzew setki razy.

Bez względu na to, czy jest, powiedzmy, 10 razy wolniej niż kompilacja wydania, oznacza to, że spędza 1/10 swojego czasu, robiąc to, co konieczne, a 9/10 robi coś innego. Jeśli podczas oczekiwania na to, po prostu naciśnij przycisk "pauza" i spójrz na stos wywoławczy, są szanse, że zobaczysz dokładnie, na czym polega problem.

It's a quick & dirty, but effective way to find performance problems.

4

Mamy wyłączony Iterator debugowanie z symboli preprocesora:

_HAS_ITERATOR_DEBUGGING=0 
_SCL_SECURE=0 

Pomogło trochę, ale wciąż nie tak szybko, jak byśmy chcieli. Ostatecznie sprawiliśmy, że nasza kompilacja debugowania jest bardziej podobna do wydania, definiując NDEBUG zamiast _DEBUG. Było kilka innych opcji, które również zmieniliśmy, ale nie pamiętam ich.

To niefortunne, że musieliśmy zrobić to wszystko, ale nasza aplikacja wymaga pewnej pracy, którą trzeba wykonać co 50ms lub jej bezużyteczności.VS2008 po wyjęciu z pudełka dałoby nam ~ 60ms razy na debugowanie i ~ 6ms razy na wydanie. Dzięki wyżej wymienionym usprawnieniom możemy uzyskać debugowanie w dół do ~ 20 ms, co jest co najmniej użyteczne.

+0

Po prostu pozwól, aby uruchomił się na płasko (tj. W sposób ciągły, bez wyzwalania z timerem). To debugowanie 10: 1: zwolnienie spowolnienia, które widzisz, jest właśnie takie, które jest naprawdę łatwe do znalezienia dzięki tej technice: http://stackoverflow.com/questions/375913/what-can-i-use-to -profile-c-code-in-linux/378024 # 378024 –

+0

... nawet przy spowolnieniu 20: 6, co oznacza, że ​​marnuje się 70% czasu. Więc jeśli weźmiesz 10 próbek, zobaczysz przyczynę na stosie na 7 +/- 1,45 próbkach, a stos pokaże Ci, dlaczego to robi, a to będzie zły powód, że możesz znaleźć pracę wokół . –

+0

Właściwie uruchomiłem profiler. Problem rozprzestrzenił się na wiele metod i wyglądało na to, że nagłówki funkcji pochłaniały cały czas, a nie ciało. Doszedłem do wniosku, że było to spowodowane dodatkowymi kontrolami wykonywanymi przez studio graficzne w trybie debugowania. – MrSlippers

2

Create a ReleaseWithSymbols konfigurację, która definiuje NDEBUG i nie są włączone optymalizacje. Zapewni to lepszą wydajność przy zachowaniu dokładnych symboli do debugowania.

Powiązane problemy