자바 컴파일러에 의한 최적화

자바 컴파일러에 의한 최적화

---

최근에 나는이 기사를 읽고 있었다 .

이 기사에 따르면 Java Compiler 즉 javac는 바이트 코드를 생성하는 동안 최적화를 수행하지 않습니다. 정말 사실인가요? 그렇다면 중복성을 제거하고 최적의 코드를 생성하는 중간 코드 생성기로 구현할 수 있습니까?

---

javac 아주 작은 최적화 만 수행합니다.

요점은 JIT 컴파일러가 대부분의 최적화를 수행한다는 것입니다. 정보가 많으면 가장 잘 작동하고 최적화를 javac수행 하면 일부가 손실 될 수 있습니다 . 경우 javac루프 언 롤링의 일종을 수행, 그것은 JIT는 일반적인 방법으로 자체 그렇게하기 어렵게 될 것이다 - 그리고 더 많은 정보를 가지고있는 최적화 것에 대해 실제로 는 대상 플랫폼을 알고로 작업.

---

이 섹션에 도착했을 때 읽기를 중단했습니다.

더 중요한 것은 javac 컴파일러가 루프 언 롤링, 대수 단순화, 강도 감소 등과 같은 간단한 최적화를 수행하지 않는다는 것입니다. 이러한 이점과 기타 간단한 최적화를 얻으려면 프로그래머는이를 수행하기 위해 javac 컴파일러에 의존하지 말고 Java 소스 코드에서이를 수행해야합니다.

첫째, Java 소스 코드에서 루프 언 롤링을 수행하는 것은 좋은 생각이 아닙니다. 그 이유 javac는 최적화 방식에서 많은 작업을 수행하지 않는 이유 는 JVM에서 JIT 컴파일러에 의해 수행되기 때문입니다. 이는 컴파일러가 할 수있는 훨씬 더 나은 결정을 내릴 수 있습니다. 왜냐하면 어떤 코드가 가장 많이 실행되고 있는지 정확히 알 수 있기 때문입니다.

---

javac컴파일러는 한 번 전달하여 최적화 된 바이트 코드를 생성 할 수있는 옵션이 지원되는 -o명령 행에 있습니다.

그러나 J2SE1.3부터 HotSpot JVM은 플랫폼과 함께 제공 되어 JIT (Just-In-Time) 컴파일 및 공통 실행 경로의 적응 형 최적화와 같은 동적 기술을 도입했습니다. 따라서이 -o버전을 시작하는 Java 컴파일러에서 무시되었습니다.

Ant javac작업과 그 optimize속성에 대해 읽을 때이 플래그를 발견했습니다 .

소스가 최적화로 컴파일되어야하는지 여부를 나타냅니다. 기본값은 off입니다. 참고 이 플래그는 단지 일에 의해 무시됩니다 때문이다 javacJDK 1.3 (컴파일시 최적화 필요가 없기 때문에)로 시작.

컴파일 시간 최적화에 비해 HotSpot JVM의 동적 최적화의 장점은 다음 페이지에 설명되어 있습니다 .

서버 VM에는 C ++ 컴파일러를 최적화하여 수행되는 동일한 유형의 최적화와 가상 메서드 호출에 대한 공격적인 인라인과 같이 기존 컴파일러에서 수행 할 수없는 일부 최적화를 지원하는 고급 적응 형 컴파일러가 포함되어 있습니다. 이것은 정적 컴파일러에 비해 경쟁 및 성능 이점입니다. 적응 형 최적화 기술은 접근 방식이 매우 유연하며 일반적으로 고급 정적 분석 및 컴파일 기술을 능가합니다.

---

나는 과거에 (FrontEnd라는 앱을 사용하여) 출력 된 Java 바이트 코드를 연구했습니다. 인라인 상수 (정적 최종)와 고정 표현식 (예 : 2 * 5 및 "ab"+ "cd")을 미리 계산하는 것을 제외하고는 기본적으로 최적화를 수행하지 않습니다. 이것이 왜 분해하기 쉬운 이유 중 하나입니다 (JAD라는 앱 사용).

또한 Java 코드를 최적화하기위한 몇 가지 흥미로운 점을 발견했습니다. 내부 루프의 속도를 2.5 배 향상시키는 데 도움이되었습니다.

메서드에는 5 개의 빠른 액세스 변수가 있습니다. 이러한 변수가 호출되면 다른 모든 변수보다 빠릅니다 (아마도 스택 유지 관리로 인해). 메서드의 매개 변수도이 5 개로 계산됩니다. 따라서 백만 번 실행되는 for 루프 내부에 코드가있는 경우 메서드 시작 부분에 해당 변수를 할당하고 매개 변수가 없습니다.

지역 변수는 또한 필드보다 빠르기 때문에 내부 루프 내에서 필드를 사용하는 경우 메서드 시작시 이러한 변수를 지역 변수에 할당하여 이러한 변수를 캐시합니다. 내용이 아닌 참조를 캐시하십시오. (예 : int [] px = this.pixels;)

---

바이트 코드를 최적화하려면 Proguard 를 사용할 수 있습니다 .

다른 사람들이 언급했듯이 주류 JVM의 JIT는 코드를 컴파일 할 때 코드를 최적화하고 더 많은 컨텍스트에 액세스 할 수 있으므로 Proguard를 능가 할 것입니다. 더 단순한 VM에서는 그렇지 않을 수 있습니다. Android 세계에서는 Dalvik (Lollipop 이전에 Android와 함께 제공된 VM)을 타겟팅 할 때 Proguard 최적화를 사용하는 것이 일반적입니다.

Proguard는 또한 바이트 코드를 축소하고 난독 화합니다. 이는 클라이언트 측 애플리케이션을 제공 할 때 필수입니다 (최적화를 사용하지 않더라도).

참고 URL : https://stackoverflow.com/questions/5981460/optimization-by-java-compiler