Medição Do Tempo

O que realmente acontece quando você tenta cronometrar algo

A medição do tempo parece simples na teoria, mas a prática rapidamente mostra quantas coisas podem dar errado. A maioria das pessoas pega um cronômetro e começa a registrar valores sem pensar que o sistema delas já tem viés. Isso importa muito mais do que se imagina. Um dos problemas que as pessoas enfrentam com frequência é a diferença entre usar um cronômetro de alta frequência (por exemplo, 100 Hz ou 1 kHz) e simplesmente registrar timestamps com clock do sistema operacional. Se você está medindo eventos que duram microssegundos, o clock do sistema operacional pode ter resolução de 1 ms a 15 ms dependendo da plataforma. Isso significa que sua medição do tempo já começa com uma margem de erro considerável antes mesmo de você registrar o primeiro dado.

medição do tempo no campo: o que ninguém conta

Aqui está algo que eu descobri na prática e que raramente aparece em tutoriais. Quando você mede o tempo de execução de algo que dura menos de 10 microssegundos usando um loop simples de repetição, o overhead do próprio laço de medição pode ser maior do que o código que você está tentando medir. Já vi gente registrar tempos de execução de "5 microssegundos" para operações que na verdade levavam 35 microssegundos porque o loop de benchmark injetava 30 microssegundos de overhead. Para contornar isso, eu sempre subtraio o baseline. Você executa o mesmo padrão de loop mas sem a operação que quer medir, registra esse tempo como overhead e subtrai dos resultados brutos. Não é elegante, mas resolve o problema na grande maioria dos casos. Quando o overhead é maior do que o sinal que você quer medir, ai sim o problema é real e você precisa mudar de estratégia — usar hardware de aquisição externo ou uma CPU com timer de alta resolução como o RDTSCP em processadores Intel/AMD modernos.

Outro ponto importante que as pessoas esquecem é a variabilidade. Uma única medição nunca é confiável. Eu sempre rodo pelo menos 1000 iterações e calculo a mediana, não a média. A média é altamente sensível a outliers causados por garbage collection, scheduler do sistema operacional, interrupções de hardware e Thermal throttling. A mediana elimina esses picos sem necessidade de filtragem manual. Se você está fazendo medição do tempo em processos distribuídos, o problema escala. Dois relógios em máquinas diferentes nunca estarão perfeitamente sincronizados, mesmo com NTP. A precisão típica do NTP em redes locais gira em torno de 1 a 5 ms, e em redes públicas pode variar de 10 ms a centenas de milissegundos. Para medições de latência entre serviços, isso é devastador se você não compensar usando timestamps relativos com handshake de sincronização ou protocolos como o Precision Time Protocol (PTP / IEEE 1588) que alcançam precisão na casa dos sub-microssegundos.

Existe ainda o problema do warm-up. Processadores modernos fazem frequency scaling dinâmico. As primeiras medições de um programa recém-iniciado tendem a ser mais lentas porque o CPU ainda está em clock baixo e os caches estão cold. Eu sempre descarto as primeiras 10% das medições antes de calcular estatísticas. Em alguns benchmarks que fiz recentemente com uma API de inference de modelo, as primeiras 5 rodadas tinham latência 3x maior que o resto — e a maioria dos artigos que li sobre o mesmo benchmark não mencionavam isso.

Configurando uma medição confiável

Aqui está o fluxo que eu uso na prática. Primeiro, defino qual precision preciso. Para coisas que levam segundos ou minutos, um timestamp simples basta. Para milliseconds, preciso de clock. Para microseconds ou menos, dependo de funções específicas da plataforma. Em Python, o padrão é usar time.perf_counter(). Ele foi projetado especificamente para medição de intervals de tempo e não é afetado por atualizações do relógio do sistema. Já em sistemas embarcados com Arduino, o micros() é a função padrão, mas você precisa estar ciente de que ela faz overflow a cada 70 minutos aproximadamente — se seu experimento dura mais que isso, precisa lidar com o wraparound manualmente.

Para C++ moderno, std::chrono::high_resolution_clock é o caminho, mas verifique se o back-end dele realmente usa um timer de hardware ou se é apenas um alias para std::chrono::system_clock, pois em algumas implementações de libc isso não é garantido. Depois de configurado o timer, faça 3 rodadas de teste preliminares para entender a variabilidade. Anote o desvio padrão. Se o CV (coeficiente de variação) estiver acima de 20%, algo está interferindo no seu sistema — feche programas em segundo plano, desative atualizações automáticas, ou rode em um ambiente mais isolado. Isso sozinho costuma reduzir o tempo de de medições inconsistentes de horas para minutos.

Uma limitação honesta que vale a pena mencionar: mesmo com todas essas precauções, medições de tempo em software nunca serão perfeitas. O scheduler do sistema operacional pode adiar sua thread por até 1 ms em sistemas com carga. Em máquinas virtuais, o hypervisor adiciona latência não determinística. Se você precisa de precisão sub-milissegundo consistente, o caminho é hardware dedicado — placas de aquisição com timer FPGA, ou no mínimo sistemas operacionais em tempo real como o PREEMPT_RT no Linux. Para a maioria dos casos do dia a dia, o fluxo descrito acima resolve. A chave é ser consistente: use sempre a mesma função de timer, o mesmo número de iterações, e o mesmo padrão de descartar aquecimento. Comparar resultados de diferentes setups de medição é uma das formas mais comuns de chegar a conclusões erradas sobre performance.