Czy mogę uniknąć powolnych wyjątków .net w DEBUG z załączonym debuggerem?

Question

Czy mogę uruchomić program, który intensywnie korzysta z wyjątków w debugerze i nie przechwytuje wyjątków w debugerze?

W szczególności próbuję użyć analizatora składni skryptów TSQL i rozumiem, że it's use of ANTLR is slow in debug mode.

Nie jest to dziwne, jeśli spojrzeć na wyjście debugowania, znajdziesz że jest to spowodowane przez Microsoft® SQL Server® 2012 Transact-SQL ScriptDom parser, ponieważ opiera się na ramach antlr , to rozwija produkcje AST, korzystając z wyjątków, dlatego powoli uruchamia się wewnątrz debuggera.

I całkowicie zrozumieć, że .net wyjątki are slow when thrown

Jak mogę uniknąć powolność podczas pracy ze standardową konfiguracją Debug z debugerem?

• Wyłączyłem intelitrace.
• Nie zdefiniowałem stałej DEBUG.
• Wyłączyłem wiadomości wyjątków w menu Narzędzia> Opcje> Debugowanie> Okno wyników.

Co jeszcze mogę spróbować?

• Ustawienie CLR Mogę zmienić poprzez app.config?
• opcja zmiany w Visual Studio?

To jest kod, którego używam do parsowania.

TSqlParser parser = new TSql110Parser(false); 
IList<ParseError> errors; 
TSqlFragment fragment = parser.Parse(new StringReader(sqltext), out errors); 

Po uruchomieniu za pomocą CTRL + F5 kończy się szybko, a przy użyciu F5 (dołączony debugger), rezygnuję z czekania.

Answer 1

Nie można zatrzymać wyjątki i pierwsze wyjątki szansę są powolne pod debugger jako proces jest wstrzymane, operacja przenosi się nad do debuggera powiedzieć, czy chce o tym wiedzieć, czy nie, następnie klient jest ponownie uruchamiany (do następnego). Tak właśnie działa Win32 Debug Api.

Zrobiłem sporo debugowania ScriptDom i najlepsze, co wymyśliłem, to parsowanie małych skryptów, które są dobrze sformułowane i poprawne.

Próbuję ograniczyć skrypt do części, która ma problem.

ed

Answer 2

To nie jest tak naprawdę .NET wyjątki, które są powolne, chociaż nie są one dokładnie demonem prędkości. Możesz rzucić gruby dziesięć tysięcy, zanim stracisz sekundę swojego życia. To w rzeczywistości twój debugger jest powolny. Sumarycznie zgłasza wyjątek w oknie wyjściowym, co jest dość kosztowne.

Bardzo łatwa do naprawienia, kliknij prawym przyciskiem myszy okno podczas debugowania i odznaczania "Komunikaty o wyjątkach". Możesz ustawić to ustawienie na stałe za pomocą Narzędzia> Opcje> Debugowanie> Okno wyników.

Jeśli nadal trzeba czekać zbyt długo, należy debugować kod za pomocą małych zestawów danych, aby po prostu nie trzeba było czekać na zawsze. Szanse, że kod nie powiedzie się na 100 000, ale nie na 100 pozycji danych, są drastycznie niskie. Ważne jest, abyś przetestował swoją aplikację pod kątem obsługi dużych ilości danych, aby sprawdzić, czy jest w stanie skalować. Ale robisz to tylko w wersji Release bez dołączonego debuggera.

Answer 3

Możliwe obejście problemu (podczas pracy z podobnym problemem, w którym biblioteka przetwarzająca obraz wyrzuciła OutOfMemoryException, jeśli był używany podczas debuggowania na szczególnie dużym zbiorze danych), należy podać punkt przerwania przed wywołaniem do 3 kod biblioteki partyjnej i odłączenie debuggera, po tym, jak punkt przerwania ponownie załączył debugger za pomocą Debugger.Launch().

#if DEBUG 
bool debuggerAttached = Debugger.IsAttached; 
if(debuggerAttached) 
{ 
    Debugger.Break(); //Detach the debugger to make the next section faster. 
} 
#endif 

TSqlParser parser = new TSql110Parser(false); 
IList<ParseError> errors; 
TSqlFragment fragment = parser.Parse(new StringReader(sqltext), out errors); 

#if DEBUG 
if(debuggerAttached && !Debugger.IsAttached) 
{ 
    Debugger.Launch(); 
} 
#endif