2009-08-31 9 views
2

J'ai la cervelle creuse la essayant de comprendre ce que le diable se passe avec la plus récente (non bêta) Visual Studio 2008 SP1:Est-ce que Visual Studio 2008 SP1 a introduit des bogues d'exécution ou suis-je folle?

Mon application construite avec OpenMP fonctionne incroyablement lent dans le débogueur, ce qui porte L'utilisation du processeur à 100%. Quand ils sont exécutés en dehors du débogueur, il ne fonctionne que lentement (pour une version release).

Mon application créée avec la bibliothèque Intel Thread Building Blocks, ou ma propre implémentation d'équipe de threads, s'exécute plus lentement dans le débogueur que lorsqu'elle est exécutée en dehors du débogueur (pour une version release).

Lorsque je vais sur mon autre ordinateur de développement sur lequel SP1 n'est pas installé, la situation est différente. L'exécution dans le débogueur ou à l'extérieur n'a aucun effet sur les performances du programme. OpenMP accélère mon application, tout comme Thread Building Blocks ou mon propre code d'équipe de threads (écrit hâtivement par exaspération pour comprendre ce problème).

Ceci est absolument sans modifications apportées à l'application, il suffit de l'exécuter à l'intérieur, ou à l'extérieur, du débogueur, SP1 par rapport à Visual Studio régulière.

Je n'ai rien trouvé à ce sujet sur Google, alors je me faufile et je dis quelque chose dans l'espoir que quelqu'un d'autre reconnaisse que cela leur arrive. Soit ça, soit je vois des choses.

+0

Avez-vous essayé d'utiliser l'analyseur de performances pour avoir une idée de ce que les méthodes consomment le plus de temps? Cela pourrait vous donner un indice sur le problème sous-jacent. – bobbymcr

+0

J'ai utilisé le profileur. Cependant, le profileur n'attache pas le débogueur, donc l'application se comporte différemment. La sortie profilée de la version multithreading est identique à la version standard. Les mêmes points chauds apparaissent - et j'ai déjà fait tout ce que je peux en termes d'optimisations. –

Répondre

2

Oui. Dans certains cas. Nous avons connu une situation similaire de ralentissement extrême après le passage à SP1. La cause de cela était des exceptions. Nous avons eu un datamodel qui a fait beaucoup d'utilisation d'un modèle d'essayer d'accéder aux clés dans un dictionnaire, ayant échouer, et attraper l'exception:

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

Ceci est juste un exemple, mais la cause était une exception du tout. Pour une raison quelconque, VS, dans le débogueur uniquement, est extrêmement lent. Note, c'était le cas avant, mais c'était pire avec le nouveau patch.

La solution consiste simplement à toujours utiliser un test. pour l'exemple de dictionnaire ci-dessus, utilisez le .TryGet ou en code personnalisé, vérifiez si votre appel va générer une exception avant de l'appeler, si c'est quelque chose qui va arriver beaucoup (c'est donc une chose 'attendue' plutôt qu'une chose 'exceptionnelle') .

Plus d'info: Exceptions and Performance

Questions connexes