Тестирование производительности Java

Я предполагаю, что вы тоже захотите сделать Something () до того, как начнете отсчет времени, чтобы код был JITter и «разогретым».

Что ж, это лишь часть тестирования производительности. В зависимости от того, что вы тестируете, вам, возможно, придется посмотреть на размер кучи, количество потоков, сетевой трафик или целый ряд других вещей. В противном случае я использую эту технику для простых вещей, которые я просто хочу увидеть, сколько времени они займут.

Имейте в виду, что разрешение System.currentTimeMillis() зависит от операционной системы. Я считаю, что Windows составляет около 15 мсек. Поэтому, если ваш doSomething() работает быстрее, чем разрешение по времени, вы получите дельту 0. Вы можете запускать doSomething() в цикле несколько раз, но тогда JVM может его оптимизировать.

Это хорошо, когда вы сравниваете одну реализацию с другой или пытаетесь найти медленную часть в своем коде (хотя это может быть утомительно). Это действительно хороший метод, и вы, вероятно, будете использовать его чаще, чем любой другой, но вы также должны быть знакомы с инструментом профилирования.

Единственный недостаток этого подхода заключается в том, что время, необходимое doSomething() для выполнения в «реальном» времени, может сильно различаться в зависимости от того, какие другие программы работают в системе и какова их нагрузка. Это делает измерение производительности несколько неточным.

Еще один точный способ отслеживания времени, необходимого для выполнения кода, при условии, что код является однопоточным, - это посмотреть на процессорное время, потребляемое потоком во время вызова. Вы можете сделать это с помощью классов JMX; в частности, с ThreadMXBean. Вы можете получить экземпляр ThreadMXBean из java.lang.management.ManagementFactory, и, если ваша платформа поддерживает его (большинство из них поддерживает), используйте метод getCurrentThreadCpuTime вместо System.currentTimeMillis для проведения аналогичного теста. Имейте в виду, что getCurrentThreadCpuTime сообщает время в наносекундах, а не в миллисекундах.

Вот пример метода (Scala), который можно использовать для измерения:

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)")
  })
}

(Не стесняйтесь переводить вышесказанное на Java!)

Эта стратегия не идеальна, но она менее подвержена изменениям в загрузке системы.

Вы смотрели инструменты профилирования в netbeans и затмение. Эти инструменты помогут вам лучше понять, что ДЕЙСТВИТЕЛЬНО занимает все время в вашем коде. Я обнаружил проблемы, которых не осознавал, используя эти инструменты.

Japex может быть вам полезен либо как способ быстрого создания тестов производительности, либо как способ изучения проблем тестирования производительности в Java через исходный код.

Код, показанный в вопросе, не является хорошим кодом для измерения производительности:

1. Компилятор может оптимизировать ваш код, изменив порядок операторов. Да, он может это сделать. Это означает, что весь ваш тест может провалиться. Он даже может выбрать встроенный тестируемый метод и переупорядочить операторы измерения во встроенном коде.

2. Точка доступа может изменить порядок ваших операторов, встроенного кода, результатов кеширования, отложить выполнение ...

3. Даже если предположить, что компилятор / точка доступа не обманули вас, вы измеряете «время стены». Что вы должны измерять, так это процессорное время (если вы не используете ресурсы ОС и не хотите их также включать или вы не измеряете оспаривание блокировок в многопоточной среде).

Решение? Используйте настоящий профайлер. Есть много чего, как бесплатные профилировщики, так и демонстрации / ограниченные по времени испытания сильных рекламных роликов.

Использование профилировщика Java - лучший вариант, и он даст вам всю необходимую информацию о коде. а именно время отклика, отслеживание вызовов потоков, использование памяти и т. д.

Я предлагаю вам ДЖЕНСОР, Java Profiler с открытым исходным кодом, за его простоту использования и отсутствие накладных расходов на процессор. Вы можете скачать его, обработать код и получить всю необходимую информацию о вашем коде.

Вы можете скачать его по ссылке: http://jensor.sourceforge.net /