Teste de desempenho Java [duplicado]
esta pergunta já tem uma resposta aqui:
- O benchmarking do cronómetro é aceitável? 13 Respostas
long startTime = System.currentTimeMillis();
doSomething();
long finishTime = System.currentTimeMillis();
System.out.println("That took: " + (finishTime - startTime) + " ms");
Duplicate : O benchmarking do cronómetro é aceitável?
9 answers
A única falha nessa abordagem é que o tempo "real" doSomething() leva para executar pode variar muito dependendo de quais outros programas estão a correr no sistema e qual é a sua carga. Isto torna a medição de desempenho um pouco imprecisa.
Uma maneira mais precisa de rastrear o tempo que leva para executar o código, assumindo que o código é de simples thread, é olhar para o tempo de CPU consumido pela thread durante a chamada. Você pode fazer isso com as classes JMX; em particular, com ThreadMXBean. Você pode obter uma instância de ThreadMXBean de java.lang.management.ManagementFactory, e, se a sua plataforma que o suporta (a maioria), use o getCurrentThreadCpuTime método no lugar de System.currentTimeMillis para fazer um teste semelhante. Tenha em mente que getCurrentThreadCpuTime relata tempo em nanossegundos, não milisegundos.
Aqui está um método de amostra (Scala) que pode ser usado para realizar uma medição:
def measureCpuTime(f: => Unit): java.time.Duration = {
import java.lang.management.ManagementFactory.getThreadMXBean
if (!getThreadMXBean.isThreadCpuTimeSupported)
throw new UnsupportedOperationException(
"JVM does not support measuring thread CPU-time")
var finalCpuTime: Option[Long] = None
val thread = new Thread {
override def run(): Unit = {
f
finalCpuTime = Some(getThreadMXBean.getThreadCpuTime(
Thread.currentThread.getId))
}
}
thread.start()
while (finalCpuTime.isEmpty && thread.isAlive) {
Thread.sleep(100)
}
java.time.Duration.ofNanos(finalCpuTime.getOrElse {
throw new Exception("Operation never returned, and the thread is dead " +
"(perhaps an unhandled exception occurred)")
})
}
(Sinta-se à vontade para traduzir o acima para Java!)
Esta estratégia não é perfeita, mas está menos sujeita a variações na carga do sistema.O código indicado na pergunta não é um bom código de medição de desempenho:
O compilador pode optar por otimizar o seu código através da reordenação de declarações. Sim, pode fazer isso. Isso significa que todo o teu teste pode falhar. Ele pode até mesmo optar por alinhar o método sob teste e reordenar as declarações de medição no código agora alinhado.
O hotspot pode optar por reordenar suas declarações, código de entrada, resultados de cache, atraso execucao...
Mesmo assumindo que o compilador/hotspot não te enganou, o que Medes é "tempo de parede". O que você deve estar medindo é o tempo da CPU (a menos que você use os recursos do OS e queira incluí-los também ou você medir a contestação da fechadura em um ambiente multi-threaded).
Usar um compilador Java é a melhor opção e dar-lhe-á toda a informação que necessita sobre o código. tempos de resposta do viz, ligações por fio, Utilisações de memória, etc
Vou sugerir-te JENSOR, um compilador Java open source, por sua facilidade de uso e sem overheads na CPU. Você pode baixá-lo, instrumentalizar o código e obter todas as informações que você precisa sobre o seu código.Você pode baixá-lo de: http://jensor.sourceforge.net/
Tenha em mente que a resolução de System.currentTimeMillis() varia entre diferentes sistemas operacionais. Acho que o Windows é por volta de 15 msec. Então, se o seu doSomething() correr mais rápido do que a resolução do tempo, você terá um delta de 0. Você poderia executar doSomething() em um loop várias vezes, mas então o JVM pode otimizá-lo.
Japex pode ser útil para você, seja como uma forma de criar benchmarks rapidamente, ou como uma forma de estudar questões de benchmarking em Java através do código fonte.