Por que breakpoint condicional diminuir a velocidade de execução do aplicativo em tempo de depuração?

Question

Quando eu usar ponto de interrupção condicional no VS2005 em vez de usar código temporário para verificar condições específicas, notei que leva mais tempo e a velocidade de execução é diminuída !! Você sabe por quê? e como resolver esse problema?

exmaple:

    int sequence = atoi(m_SequenceNumber.GetAscii());
    if( sequence == 392914)//temporary code to check to step into code
    {
        int x = 0;//I put breakpoint here
    }

O código anterior será executado mais rapidamente do que se utilizado ponto de interrupção condicional com (sequência == 392.914)

Answer 1

É melhor (se possível) para usar um ponto de controle de memória do que um ponto de interrupção condicional. Um ponto de interrupção condicional (como outros têm apontado) tem para executar código adicional cada vez que o ponteiro de execução vai além desse ponto, a fim de determinar se ele iria quebrar ou não - obviamente isso leva tempo adicional. Um ponto de controle de memória de um certo tipo começa a usar certos registros de hardware especiais -. Há um limite de quantos watchpoints você pode definir que pode se acelerada, mas se você pode usá-los não há quase nenhuma perda de velocidade

Um ponto de controle de memória estiver usando a janela de ponto de interrupção. Você não defini-lo em uma linha de código, mas sim em um endereço na memória. Isto sugere a limitação óbvia, ele só funciona para coisas que você pode realmente ter o endereço de, como variáveis ??globais e áreas de alocação dinâmica de memória (usando new etc). Você está limitado na quantidade de memória que você está autorizado a assistir (com base na CPU, eu acho que você provavelmente obter registros mais ou menos especiais atribuídos).

Eu não estou realmente sentado na frente do VS agora, mas a grosso modo, você clique direito na janela de pontos de interrupção e escolher algo como "novo ponto de interrupção de dados". Em seguida, introduza o endereço da memória e o tamanho em bytes. Sempre que o valor muda o seu ponto de controle dispara. Isto é particularmente útil para descobrir problemas de corrupção de memória.

Answer 2

Eu executar para esse problema no passado bem e nunca realmente encontrou uma maneira de continuar a usar o condicional pontos de interrupção dentro de um grande laço sem afetar o desempenho. Eu aprendi que você pode inserir um código temporário como este, que não iria afetar o desempenho e causaria VS para quebrar (o mesmo comportamento como um Breakpoint condicional).

if ( condition ) Debugger.Break();

Answer 3

Pense em como você poderia implementar um ponto de interrupção condicional se você estivesse escrevendo um depurador. A única vez que o depurador tem a oportunidade de avaliar a condição é quando o ponto de interrupção é atingido. Assim, mesmo que o ponto de interrupção está condicionado tanto quanto você está em causa, na medida em que o processador está em causa o ponto de interrupção está sendo cada vez hit a instrução é executada. O depurador obtém controle e faz o seguinte:

• determina que o ponto de interrupção é condicional
• avalia a expressão
• Se a expressão for falsa, o depurador continua a execução
• Caso contrário, as voltas do depurador controle sobre a você

Assim, mesmo se você nunca vê o hit breakpoint (porque a condição não for atendida), o depurador pode ser fielding o ponto de interrupção e avaliar os milhares condição de vezes por segundo (ou mais talvez).

Answer 4

Eu suponho que é porque leva tempo para executar a condição. Ainda é muito mais rápido do que pisar manualmente o número necessário de tempos difíceis.

Answer 5

código temporário Adicionado pode ser otimizado (pelo menos um pouco) pelo compilador. breakpoint condicional provavelmente salta para algum código visual studio que irá recuperar manualmente as informações necessárias para saber se ele realmente tem que fazer uma pausa ou não.

Isso de alguma forma explicar por que é preciso mais tempo. Mas eu estou apenas adivinhando.