Pourquoi mon code STL fonctionne-t-il si lentement lorsque le débogueur/IDE est connecté?

Question

Je cours le code suivant, en utilisant Visual Studio 2008 SP1, sur Windows Vista Business x64, machine quad core, ram 8gb.

Si je compile une version de version et l'exécute à partir de la ligne de commande, elle indique 31 ms. Si je le lance ensuite à partir de l'IDE, en utilisant F5, il signale 23353ms.

Voici les temps: (tous Win32 construit)

• DEBUG, ligne de commande: 421ms
• DEBUG, de l'IDE: 24,570ms
• RELEASE, ligne de commande: 31ms
• DE PRESSE , à partir de l'IDE: 23,353ms

Code:

#include <windows.h> 
#include <iostream> 

#include <set> 
#include <algorithm> 
using namespace std; 

int runIntersectionTestAlgo() 
{ 

    set<int> set1; 
    set<int> set2; 
    set<int> intersection; 


    // Create 100,000 values for set1 
    for (int i = 0; i < 100000; i++) 
    { 
     int value = 1000000000 + i; 
     set1.insert(value); 
    } 

    // Create 1,000 values for set2 
    for (int i = 0; i < 1000; i++) 
    { 
     int random = rand() % 200000 + 1; 
     random *= 10; 

     int value = 1000000000 + random; 
     set2.insert(value); 
    } 

    set_intersection(set1.begin(),set1.end(), set2.begin(), set2.end(), inserter(intersection, intersection.end())); 

    return intersection.size(); 
} 

int main(){ 
    DWORD start = GetTickCount(); 

    runIntersectionTestAlgo(); 

    DWORD span = GetTickCount() - start; 

    std::cout << span << " milliseconds\n"; 
} 

Answer 1

Fonctionnant sous un débogueur Microsoft (windbg, kd, cdb, Débogueur Visual Studio) par les forces par défaut Windows utilisez le tas de débogage au lieu du tas par défaut. Sur Windows 2000 et versions ultérieures, le tas par défaut est le Low Fragmentation Heap, ce qui est incroyablement bon par rapport au tas de débogage. Vous pouvez interroger le type de tas que vous utilisez avec HeapQueryInformation.

Pour résoudre votre problème, vous pouvez utiliser l'une des nombreuses options recommandées dans cet article KB: Why the low fragmentation heap (LFH) mechanism may be disabled on some computers that are running Windows Server 2003, Windows XP, or Windows 2000

Pour Visual Studio, je préfère ajouter _NO_DEBUG_HEAP=1-Project Properties->Configuration Properties->Debugging->Environment. Cela fait toujours l'affaire pour moi.

Answer 2

Ainsi, il semble que ce soit juste ce qui se passe quand on attache le débogueur. Cependant, je ne peux pas me passer de 30ms à 23000ms à cause de cela, surtout quand le reste de mon code semble fonctionner aussi vite que le débogueur soit attaché ou non.

Answer 3

Si vous appuyez sur pause dans l'EDI VS, cela indique que le temps supplémentaire semble être passé en malloc/free. Cela m'amène à croire que le support de débogage dans malloc et l'implémentation libre de MS ont une logique supplémentaire si le débogueur est attaché. Cela expliquerait l'écart de temps entre la console et le débogueur.

EDIT:. Confirmé en exécutant avec CTRL + F5 v F5 (1047ms v 9088ms sur ma machine.)