스톱워치 벤치마킹을 사용하는 사람이 있습니까? 아니면 성능 도구를 항상 사용해야합니까? Java에 사용할 수있는 좋은 무료 도구가 있습니까? 어떤 도구를 사용하십니까?
내 우려를 명확히하기 위해 스톱워치 벤치마킹은 운영 체제 일정으로 인해 오류가 발생할 수 있습니다. 주어진 프로그램 실행에서 OS는 타이밍을 맞추고있는 기능의 중간에 다른 프로세스 (또는 여러 프로세스)를 예약 할 수 있습니다. Java에서는 JVM 스케줄러가 혼합에 조금 더 무작위성을 던지기 때문에 스레드 응용 프로그램의 시간을 측정하려는 경우 상황이 조금 더 나빠집니다.
벤치마킹시 운영 체제 스케줄링을 어떻게 처리합니까?
답변:
의미있는 반복을 충분히 측정한다면 스톱워치 벤치마킹은 괜찮습니다 . 일반적으로 몇 초의 총 경과 시간이 필요합니다. 그렇지 않으면 일정 예약 및 프로세스에 대한 기타 O / S 중단으로 인해 결과가 쉽게 크게 왜곡됩니다.
이를 위해 나는 오래 전에 구축 한 약간의 정적 메서드 세트를 사용합니다 System.currentTimeMillis().
프로파일 링 작업 을 위해 몇 년 동안 jProfiler 를 사용해 왔으며 매우 훌륭하다는 것을 알았습니다. 나는 최근 에 웹 사이트에서 훌륭해 보이는 YourKit을 살펴 봤지만 개인적으로 전혀 사용하지 않았습니다.
일정 중단에 대한 질문에 답하기 위해 일관성이 달성 될 때까지 반복 실행을 수행하고 / 실제로 프로세스 일정에서 비정상적인 결과를 걸러내는 작업을 수행합니다. 또한 스레드 스케줄링이 5 초에서 30 초 사이의 실행에 실질적인 영향이 없음을 발견했습니다. 마지막으로, 몇 초 임계 값을 통과 한 후 일정 예약은 결과에 거의 영향을 미치지 않습니다. 5 초 실행은 시간 / 반복에 대해 5 분 실행과 동일한 평균을냅니다.
테스트 된 코드가 실제 생활에서 시간이 지남에 따라 실행될 것으로 예상되는 횟수에 따라 JIT를 "워밍업"하기 위해 테스트 된 코드를 약 10,000 번 사전 실행하는 것을 고려할 수도 있습니다.
충분한 시간 간격을 측정하는 한 완전히 유효합니다. 총 경과 시간이 1 초 이상이되도록 테스트하려는 내용을 20 ~ 30 번 실행합니다. System.currentTimeMillis ()를 기반으로 한 시간 계산은 0ms 또는 ~ 30ms가되는 경향이 있습니다. 나는 당신이 그것보다 더 정확한 것을 얻을 수 있다고 생각하지 않습니다. 작은 시간 간격을 측정해야하는 경우 System.nanoTime ()을 사용해 볼 수 있습니다.
스톱워치는 실제로 최고의 벤치 마크입니다!
실제 사용자 응답 시간은 실제로 중요한 시간입니다.
사용 가능한 도구를 사용하여이 시간을 확보하는 것이 항상 가능한 것은 아닙니다. 예를 들어 대부분의 테스트 도구에는 브라우저가 페이지를 렌더링하는 데 걸리는 시간이 포함되어 있지 않으므로 CSS가 잘못 작성된 복잡한 페이지는 테스트에 대한 1 초 미만의 응답 시간을 표시합니다. 도구이지만 사용자에 대한 응답 시간은 5 초입니다.
이 도구는 자동화 된 테스트 및 문제 결정에 적합하지만 실제로 측정하려는 내용을 놓치지 않습니다.
프로파일 러는 성능 문제를 진단하고 수정하는 데 도움이 될 수있는보다 자세한 정보를 제공합니다.
실제 측정 측면에서 스톱워치 시간은 사용자가인지하는 것이므로 사물이 허용 가능한 한도 내에 있는지 확인하려면 스톱워치 시간이 좋습니다.
그러나 실제로 문제를 수정하려는 경우 프로파일 러가 정말 도움이 될 수 있습니다.
타이밍을 테스트하는 방법에 따라 다른 답을 얻을 수 있으므로 현실적인 반복 횟수를 테스트해야합니다. 작업을 한 번만 수행하면 평균적으로 많은 반복을 수행하는 것이 잘못 될 수 있습니다. JVM이 워밍업 된 후 걸리는 시간을 알고 싶다면 타이밍에 포함되지 않은 많은 (예 : 10,000) 반복을 실행할 수 있습니다.
또한 System.nanoTime()훨씬 더 정확하므로 사용 하는 것이 좋습니다 . 테스트 시간이 약 10 마이크로 초 이하인 경우 너무 자주 호출하고 싶지 않거나 결과가 변경 될 수 있습니다. (예를 들어 5 초 동안 테스트하고 이것이 언제 끝났는지 알고 싶다면 반복이 매우 빠르다는 것을 안다면 1000 반복마다 nanoTime 만 얻습니다)
핵심 질문은 수술의 복잡성과 시간입니다.
때로는 물리적 스톱워치 측정을 사용하여 계산하는 데 몇 분, 몇 시간, 며칠 또는 몇 주가 걸리는지 확인합니다 (저는 몇 초와 몇 분이 있더라도 몇 일의 실행 시간이 들리지 않는 애플리케이션으로 작업하고 있습니다. 가장 일반적인 기간).
그러나 링크 된 기사에서 언급 된 자바 밀리 호출과 같이 컴퓨터의 모든 종류의 시계 시스템에 대한 호출로 제공되는 자동화는 무언가가 실행되는 시간을 수동으로 확인하는 것보다 분명히 우수합니다.
프로파일 러는 작동 할 때 훌륭하지만 응용 프로그램에 적용하는 데 문제가있었습니다. 일반적으로 동적 코드 생성, DLL의 동적로드, 두 개의 기본 제공 Just-In-Time 컴파일 스크립팅 언어에서 수행되는 작업이 포함됩니다. 내 응용 프로그램. 그들은 종종 단일 소스 언어와 복잡한 소프트웨어에 대한 기타 비현실적인 기대를 가정하는 것으로 제한됩니다.
저는 오늘 여러 dBase 파일에서 정보를 검색하고 수집하는 프로그램을 실행했는데 실행하는 데 1 시간 넘게 걸렸습니다 . 코드를 살펴보고 병목 현상이 무엇인지 추측하고 알고리즘을 약간 개선 한 다음 프로그램을 다시 실행했는데 이번에는 2.5 분 만에 완료되었습니다 .
새 버전이 크게 개선되었음을 알리기 위해 멋진 프로파일 링 도구 나 벤치 마크 제품군이 필요하지 않았습니다. 실행 시간을 더 최적화해야한다면 좀 더 정교한 분석을 수행했을 것입니다. 그러나 이것은 필요하지 않았습니다. 이러한 종류의 "스톱워치 벤치마킹"은 상당히 많은 경우에 허용되는 솔루션이며 이러한 경우에는 더 고급 도구를 사용하는 것이 실제로 더 많은 시간이 소요된다는 것을 알게되었습니다.