프로필 기반 최적화에는 몇 가지주의 사항이 있으며, 그 중 하나는 연결된 Wiki 기사에서도 언급되어 있습니다. 코드가 실제로 사용자 또는 다른 코드에서 사용되는 방식을 나타내는 유효한 샘플은
- 입니다. 주어진 플랫폼 (CPU, 메모리 + 기타 하드웨어, OS, 기타)에 대한
성능 측면에서 볼 때 일반적으로 (다소간) 동일하다고 간주되는 플랫폼 (예 : Linux에서 실행되는 단일 코어, 이전 Athlon과 512M, 6 코어 Intel과 8G 비교, 그러나 매우 다른 커널 버전이 있음). 주어진 JVM 및 해당 구성에 대한
이러한 변경 사항이 있으면 프로파일 링 결과 (및이를 기반으로하는 최적화)가 더 이상 유효하지 않습니다. 대부분의 최적화는 여전히 유익한 영향을 미치지 만 그 중 일부는 차선책 (또는 성능 저하)이 될 수 있습니다.
언급했듯이 JIT JVM은 프로파일 링과 매우 유사한 기능을 수행하지만 실제로 수행합니다. '핫스팟'이라고도 불리는 이유는 실행 된 코드를 지속적으로 모니터링하고 자주 실행되는 핫 스폿을 찾아 해당 부분 만 최적화하려고하기 때문입니다. 이 시점에서 코드에 대한 더 많은 지식을 활용할 수 있습니다 (코드의 컨텍스트, 다른 클래스에서 사용하는 방법 등) - 사용자와 다른 답변에서 언급했듯이 - 코드로 더 나은 최적화를 수행 할 수 있습니다. 정적 인 것. 모니터링을 계속하고 필요하다면 나중에 최적화의 또 다른 차례를 수행 할 것이며 이번에는 더 많은 비용이 드는 최적화를 찾는 것이 더욱 힘들어집니다.
실생활 데이터 (사용 통계 + 플랫폼 + 구성)를 작업하면 앞에서 언급 한 사항을 피할 수 있습니다.
"프로파일 링"+ JIT-ing에 소요되는 추가 비용이 있습니다. 대부분의 시간은 꽤 잘 보냈다. 당신이주의를 피할 수 있다면
나는 프로파일 유도 최적화는 여전히하지만 일부 특별한 경우, (그것을 이길 짝수 또는) 그와 경쟁 할 수있는 것 같아요 :
- 당신은 당신의 샘플이 아주 확실하다 실생활 시나리오를 잘 나타내주고 실행 중에 너무 많이 변하지 않을 것입니다.
- 타겟 플랫폼을 매우 정확하게 알고 프로파일 링을 수행 할 수 있습니다.
- 물론 JVM과 그 구성을 알고/제어하십시오.
거의 발생하지 않으며 일반적으로 JIT에서 더 나은 결과를 얻을 것이라고 추측하지만 나는 그것에 대한 증거가 없습니다.
JIT 최적화를 수행 할 수없는 JVM을 대상으로하는 경우 프로필 기반 최적화에서 가치를 얻을 수있는 또 다른 가능성 (대부분의 소형 장치에는 이러한 JVM이 있다고 생각합니다).
기타 답변에서 언급 한 단점은 피하는 것이 매우 쉽습니다. 정적/프로필 안내 최적화가 느린 경우 (아마도 경우 일 수 있습니다) 그런 다음 릴리스 (또는 테스터로가는 RC) 또는 야간 빌드 동안 만 수행하십시오 (시간은별로 중요하지 않습니다).
더 큰 문제는 좋은 샘플 테스트 케이스를 갖는 것입니다. 그것들을 생성하고 유지하는 것은 일반적으로 쉽지 않으며 많은 시간이 걸립니다. 특히 자동으로 실행할 수 있도록하려면이 경우 매우 중요합니다.
동의. 일부 AOT 컴파일러 (gcc가 내가 아는 유일한 사람이지만 다른 사람이있을 수도 있음)는이 기능을 가지고 있으며 "링크 타임 최적화"라고 부릅니다. 그것은 비교적 새로운 것이지만, 어떤 기능이 가장 자주 호출 될지 추측하기 위해 여전히 연관되어 있습니다. OP가 언급 한 그 문제에 대한 "프로파일 기반 최적화"가 있긴하지만. – delnan