No Visual Studio 2008 SP1 introduce errores de tiempo de ejecución o estoy loco?

Question

He estado devanando los sesos tratando de averiguar qué diablos está pasando con el más reciente (no beta) de Visual Studio 2008 SP1:

Mi aplicación construida con OpenMP funciona increíblemente lento en el depurador, con lo que el uso de CPU al 100%. Cuando se ejecutan fuera del depurador, simplemente corre lentamente (para una versión de lanzamiento).

Mi aplicación integrada con la biblioteca de bloques de construcción Intel Thread, o mi propia aplicación equipo de hilo, funciona más lento en el depurador que cuando se ejecuta fuera del depurador (para una versión de lanzamiento).

Cuando voy a mi otra máquina de desarrollo, que no ha tenido instalado SP1, la situación es diferente. Se ejecuta en el depurador, o en el exterior, no tiene ningún efecto sobre el rendimiento del programa. OpenMP acelera mi solicitud, al igual que Thread bloques de construcción o equipo de mi propio código de rosca (escrito apresuradamente de la exasperación de averiguar este problema).

Este es sin ningún tipo de cambios realizados en la aplicación, simplemente se ejecuta dentro, o fuera, del depurador, SP1 frente regular de Visual Studio.

he encontrado nada sobre esto en Google por lo que estoy jugando el cuello y decir algo con la esperanza de que alguien pueda reconocer esto está sucediendo a ellos. O eso, o que estoy viendo cosas.

Answer 1

Sí. En algunos casos. Hemos experimentado una situación similar de gran desaceleración después de cambiar a SP1. La causa de esto fue excepciones. Tuvimos un modelo de datos que hizo que una gran cantidad de uso de un patrón de tratar de acceder a las claves en un diccionario, que tiene que fallar, y la captura de la excepción:

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

Esto es sólo un ejemplo, pero la causa fue ninguna excepción en absoluto. Por alguna razón, VS, sólo en el depurador, es extremadamente lento. Tenga en cuenta, este era el caso antes, pero fue significativamente peor con el nuevo parche.

La solución es simplemente usar siempre una prueba. para el ejemplo de diccionario anteriormente, utilizar el .TryGet o bajo control de código personalizado si su llamada generará una excepción antes de llamar, si es algo que sucede con frecuencia (por lo tanto es una cosa 'espera' en lugar de algo 'excepcional') .

Más información: Excepciones y rendimiento