자바 표현 최적화

나는 모든 장소 (아마도 20 ~ 30 개 인스턴스)를 통해 수행하는 코드를이 :자바 표현 최적화

논리적으로

<widget>.setVisible((condition == VIEW) || (condition == EDIT));

내가 자바 컴파일러는 아마 전면 그것을 계산이 최적화됩니다 것을 이해한다 계산 된 부울을 사용하면됩니다.

제 질문은 실제로 이것이 사실인지 확인할 수있는 방법이 있습니까?

설명은

condition 건설 과거를 수정하는 방법과 private 클래스 멤버입니다.

출처

2012-03-23 Karlson

필자는이를 최적화하기 위해 컴파일러에 의존하지 않을 것입니다. 가능한 한 특정 상황에서만 유용합니다 :'condition'이 메소드라면, 지역 변수가 거의 가능하고 어쩌면 할 수 있습니다. 그렇지 않다면, 그것은 setVisible sideeffects, 다른 쓰레드 등에 의해 변경 될 '조건'의 확실성에 달려있다. – dronus

@ Karlson : 보이는 구성 요소가 상태를 바꿀 때 표시되거나 숨겨 질 필요가있을 때 어떤 종류의 초고 무거운 포병이 후드 아래로 이동하는지 전혀 알지 못한다고 생각합니다. 당신이이 체크를 최적화 할 필요가 있다고 생각한다면, 종종 이렇게 부르는 것을 끝낼지도 모릅니다. 앱을 느리게 할 것이기 때문에 큰 문제가됩니다. – TacticalCoder

또한 위젯과 'setVisible'은 비용이 많이 드는 GUI 연산이나 이와 비슷한 것을 가정합니다. 이것은 일반적인 GUI 프레임 워크 코드와 관련하여 그러한 표현식의 실행 된 방도의 방대한 차이로 인해 최적화 된 부울 표현식의 효과를 보이지 않게합니다. – dronus

javap으로 클래스 파일을 디스 어셈블합니다 (예 : javap).

javap -c com.example.ClassName

바이트 코드 소스를 확인하십시오. 하지만 왜 그냥 부울 변수로 추출하여 최적화를 보장하지?

출처

2012-03-23 15:28:51 paislee

바이트 코드를 디스 어셈블합니다.

즉, 이러한 종류의 최적화는 런타임에 수행 될 수 있으며 condition의 선언에 따라 달라질 수 있으며 조건의 위치 등에 따라 달라질 수 있습니다. 이와 같은 최적화 추적은 가장 간단한 사용 사례가 아닌 모든 경우에있어 중요하지 않습니다.

출처

2012-03-23 15:24:46

실제로 이것이 사실인지 확인할 방법이 있습니까?

당신은

그러나, 나는이 전략 성사 내포 생각 등 핫스팟에 의해 생성 된 머신 코드를 다음 바이트 코드 분해보고이를 확인하기 위해을 시도 할 수 있습니다. 결과는 컴파일러/JVM과 condition의 정확한 특성에 의존하기 때문에 그것은 또한 허약 (이 지역? 클래스 멤버? final? volatile?)

는 성능상의 이유로 최적화 [1 걱정하는 경우 ], 내 충고는 일반적인 표현을 분해함으로써 수동으로 수행하는 것이 될 것입니다.

[1] 코드를 프로파일 링 한 것으로 보아 이것이 병목 현상이라는 사실을 알고 있습니다.

출처

2012-03-23 15:40:02 NPE

예, 그 중 하나가 아닙니다. – Karlson

자바 표현 최적화

답변

관련 문제