Visual Studio 2008 SP1 ha introdotto bug di runtime o sono pazzo?

Question

Mi sono scervellato cercando di capire cosa diavolo sta succedendo con il più recente (non beta) Visual Studio 2008 SP1:

La mia app creata con OpenMP funziona incredibilmente lentamente nel debugger, portando l'utilizzo della CPU al 100%.Quando vengono eseguiti all'esterno del debugger, vengono semplicemente eseguiti lentamente (per una build di rilascio).

La mia app creata con la libreria Intel Thread Building Blocks o l'implementazione del mio team di thread viene eseguita più lentamente nel debugger rispetto a quando viene eseguita all'esterno del debugger (per una build di rilascio).

Quando utilizzo l'altro computer di sviluppo su cui non è installato SP1, la situazione è diversa.L'esecuzione nel debugger o all'esterno non ha alcun effetto sulle prestazioni del programma.OpenMP accelera la mia applicazione, così come Thread Building Blocks o il codice del mio team di thread (scritto in fretta per l'esasperazione per capire questo problema).

Questo avviene senza alcuna modifica apportata all'app, basta eseguirla all'interno o all'esterno del debugger, SP1 rispetto al normale Visual Studio.

Non ho trovato nulla a riguardo su Google, quindi mi metto in gioco e dico qualcosa nella speranza che qualcun altro possa riconoscere che ciò che sta accadendo a loro.O è così, oppure sto vedendo delle cose.

Answer 1

SÌ.In certi casi.Abbiamo riscontrato una situazione simile di estremo rallentamento dopo il passaggio a SP1.La causa di ciò erano le eccezioni.Avevamo un modello di dati che faceva molto uso di un modello di tentativo di accedere alle chiavi in ​​un dizionario, fallendo e rilevando l'eccezione:

try {
  var a = dict[key];
} catch(KeyNotFoundException) {
  dict[key] = default;
  a = default;
}

Questo è solo un esempio, ma la causa non è stata affatto un'eccezione.Per qualche motivo, VS, solo nel debugger, è estremamente lento.Tieni presente che prima era così, ma con la nuova patch le cose erano significativamente peggiori.

La soluzione è semplicemente usare sempre un test.per l'esempio del dizionario sopra, usa .TryGet o nel codice personalizzato controlla se la tua chiamata genererà un'eccezione prima di chiamarla, se è qualcosa che accadrà spesso (quindi è una cosa "attesa" invece di una cosa "eccezionale") .

Ulteriori informazioni: Eccezioni e prestazioni