A execução de "milli" é uma boa ideia?

5

Acabei de me deparar com o projeto da Caliper e parece muito bom. Ao ler a introdução de microbenchmarks , temos a sensação de que os desenvolvedores não sugeririam usar a estrutura se o O benchmark demora mais de um segundo ou mais. Eu olhei para o código e parece que um RuntimeOutOfRangeException é realmente lançado se um cenário demorar mais de 10 segundos para ser executado.

Você poderia me explicar quais são os problemas com a execução de benchmarks maiores?

Minha motivação para usar o Caliper foi comparar duas implementações de algoritmos de junção. Definitivamente, eles serão executados por algum tempo e farão algum disco IO, mas executar o banco de dados inteiro dificultaria a comparação, porque a configuração dos algoritmos e a visualização dos resultados seria uma dor.

    
por Konstantin Weitz 26.06.2012 / 00:09
fonte

3 respostas

5

Uma das razões para usar o paquímetro, em vez de apenas escrever ingenuamente o seu próprio código de benchmarking, é que a pinça percorre um longo caminho para evitar algumas das armadilhas de se escrever micro-benchmarks. Por exemplo, um bom benchmark deve primeiro executar o código em uma fase de aquecimento que garanta que todo o código relevante receba o JITed. Deve também assegurar que o dobro de iterações consuma o dobro do tempo; se não, isso sugere que a JVM está otimizando o trabalho.

Tudo isso significa que, para avaliar corretamente o código, o calibrador precisa executar lotes de iterações. Para uma tarefa que deve levar algo da ordem de microssegundos, isso é razoável. Mas se uma única iteração levar mais de 10 segundos, isso significa que a execução da pinça vai demorar muito tempo. Minha suposição é que a equipe da Caliper decidiu que, por causa disso, uma tarefa que leva mais de 10 segundos para ser executada era muito mais provável que resultasse de erro do programador do que uma escolha intencional de escrever um benchmark que levaria horas para ser executada. Ao sair cedo, ajuda os programadores a perceber rapidamente que precisam consertar um bug, em vez de deixar a máquina girar por horas.

    
por 04.07.2012 / 00:57
fonte
1

Uma ideia com design orientado a teste é executar todos os testes de unidade ao criar um projeto, o que permite capturar regressões funcionais rapidamente, antes de confirmar as alterações que as causaram. Para que isso funcione, todos os seus testes precisam ser concluídos rapidamente.

Se todos os seus testes de desempenho forem executados rapidamente, eles poderão ser incluídos em sua estrutura de teste (não sei se é para isso que o Caliper deve funcionar, mas o Google está strongmente ligado ao TDD ...). De qualquer forma, o objetivo de adicionar pontos de referência à sua infra-estrutura orientada a testes seria detectar rapidamente grandes regressões de desempenho. Assim, para esse tipo de uso, você queria sinalizar demorando muito tempo como um erro.

    
por 26.06.2012 / 00:19
fonte
1

Muitas lentidões de código ocorrem em pequenos e apertados loops. Se você sabe que é onde seu tempo está sendo gasto, um micro-benchmark pode ajudá-lo a otimizar apenas esse pequeno código.

Os testes de unidade precisam ser concluídos em um período de tempo razoável. É realmente raro eu escrever um teste de unidade que demore mais do que um segundo ou dois para ser executado, já que eu posso ter dois ou trezentos desses testes ou mais em uma montagem de teste.

    
por 26.06.2012 / 00:14
fonte