-2
Java 코드를 최적화하는 방법에 대한 인터넷 가이드가 많이 있지만 Groovy에는 그다지 많은 부분이 없습니다. Groovy 코드가 더 빨리 실행되어야 할 때 Groovy 관련 사항은 무엇을주의해야합니까?Groovy 코드를 최적화하는 방법은 무엇입니까?
A
답변
1
예비 :이 답변은 비 indy 핫스팟 VM (OpenJDK, Oracle JVM) 버전 1.8에서 실행되는 Groovy 코드에만 해당됩니다. Indy 옵션은 동적 호출을 많이 개선 할 것을 약속하지만, 이에 대한 경험이 없습니다.
최적화에 대한 일반 면책 조항 : MEASURE FIRST! 코드에서 가장 느린 부분은 예상하지 못한 부분 일 가능성이 높습니다. 내가 honest profiler을 사용한 JVM 코드의 경우 한계가 있지만 CPU 바인딩로드의 경우 JVM 체크 포인트에 의존하는 프로파일 러보다 훨씬 낫습니다. 그리고 그것은 무료입니다.
그루비 코드를 최적화 :
- 모든 핫 코드에
@CompileStatic적용! 어딘가에서 중간 뜨거운 방법을 놓치지 않도록하십시오. CompileStatic이 없으면 JVM의 최적화 기능이 쓸모가 없습니다. - Groovy 수집 방법을 피하십시오. 그루비 수집 방법 (
each,collect등)은 JVM에 의해 cannot be inlined이 올바르게 닫히기 때문에 느립니다. Java 스타일의 for 및 each-for 루프로 루프를 대체하십시오. 단순한 루프의 경우 Groovy 구문과 같이 읽기 쉽습니다. 보다 복잡한 경우에는 Guava과 같은 원시 Java 콜렉션 메소드 또는 라이브러리를 살펴보십시오. - 가능한 경우 폐쇄하지 마십시오. 클로저 호출이 느립니다. 모든 코드가
@CompileStatic이라하더라도 클로저 호출은 여전히 느리고 블록 최적화를 차단하는 Groovy의 동적 디스패치 로직을 사용합니다. 하나의 메소드를 가진 평범한 구 Java 내부 클래스가 대안이 될 수 있습니다. 불행하게도 이것은 추한 것입니다. Groovy는 Java의 익명 클래스 구문을 지원하지 않습니다. 그러나 그 트레이드 오프에 유의하십시오. as키워드는 사용하지 마십시오.as은 잠재적으로 값 비싼 전환을 수행하며 캐스팅과 다릅니다.foo as Bar대신에(Bar) foo이라고 적어주세요. 그루비 캐스트는 Java의 캐스트보다 조금 비싸지 만 전환 수보다 훨씬 저렴합니다. Groovy 형변환은 다른 숫자 유형 간 변환과 같은 Java 형변환보다 약간 더 효과적입니다. 전환은 유용 할 수 있지만 실제로 전환을 원하고 캐스트를 원할 경우에만 사용하고 비용은 귀하의 경우에 가치가 있습니다.- 일반적인 Java 최적화 기술을 적용하십시오. Groovy는 자바처럼 잘 작동합니다. 모든 최종 만들기 (이 특정 그루비 아니지만, 여전히 적용)
- :
물건 당신은 귀찮게 할 필요가 없습니다. 실제로 로컬 변수 또는 매개 변수가 변경되지 않으면 JVM은이를 확인하고 최종 것처럼 매개 변수를 최적화합니다. 최종 정적 클래스 멤버가 어떤 경우에는 여전히 도움이 될 수 있지만 컴파일러는 예를 들어 최종 필드와 비 최종 필드에 대해서도 마찬가지입니다.
- 개체 할당 방지에 많은 노력을 기울입니다. 객체 할당은 매우 저렴합니다. 1 세대 복사 가비지 컬렉터는 라이브 오브젝트 만 복사하고, 죽은 오브젝트는 무시하므로 수명이 짧은 오브젝트에 대한 가비지 콜렉션 비용은 거의 들지 않습니다.그리고 일반적으로 (현재) 가비지 수집기는 별도의 스레드에서 많은 작업을 수행하므로 모든 프로세서 코어가 포화되지 않으면 가비지 수집 자체가 사용자의 (단일 스레드) 코드를 느리게 감속하지 않습니다. 객체를 재사용하면 불쾌한 버그가 생길 수 있으며 때로는보기 흉합니다. 프로파일 링이 가비지 수집에 상당한 시간을 소비하고 있음을 나타낼 경우에만 오브젝트 작성을 조사해야합니다.