자바 퍼포먼스

Java performance
이 글은 자바 플랫폼 성능을 총체적으로 보여주는 것이다. Java 성능 및 보다 일반적인 Java 언어에 대한 비판은 Java의 비판을 참조하십시오.

소프트웨어 개발에서 자바 프로그래밍 언어는 역사적으로 가장 빠른 3세대 타입의 C, C++[1]보다 느린 것으로 여겨졌다. 주된 이유는 다른 언어 설계 때문인데, 컴파일 후 자바 프로그램은 C와 C++ 프로그램과 마찬가지로 컴퓨터의 프로세서에서 직접 네이티브 코드로 실행되지 않고 자바 가상 머신(JVM)에서 실행된다. 1990년대 후반과 2000년대 초반에 이 언어가 빠르게 대중화된 이후 자바에서 많은 비즈니스 소프트웨어가 쓰여져 왔기 때문에 성능은 우려할 만한 문제였다.

1990년대 후반부터 Java 프로그램의 실행 속도는 JIT(Just-in-Time 컴파일) 도입(1997년 Java 1.1의 경우), [2][3][4]더 나은 코드 분석을 지원하는 언어 기능의 추가, JVM에서의 최적화(2000년 HotSpot이 Sun의 JVM의 디폴트(Default)가 되는 등)를 통해 크게 향상되었다. ARM의 Jazelle이 제공하는 것과 같은 자바 바이트 코드의 하드웨어 실행도 상당한 성능 향상을 제공하기 위해 탐구되었다.

컴파일된 Java 바이트코드의 성능은 주어진 작업이 호스트 Java 가상 머신(JVM)에 의해 최적으로 관리되는 방법과 JVM이 이를 통해 컴퓨터 하드웨어와 운영 체제(OS)의 기능을 얼마나 잘 활용하느냐에 따라 달라진다. 따라서 모든 Java 성능 테스트 또는 비교는 항상 사용된 JVM의 버전, 벤더, OS 및 하드웨어 아키텍처를 보고해야 한다. 유사한 방법으로, 기본적으로 컴파일된 동등한 프로그램의 성능은 생성된 기계 코드의 품질에 따라 달라지기 때문에, 시험이나 비교 또한 사용된 컴파일러의 이름, 버전, 벤더, 그리고 활성화된 컴파일러 최적화 지침 등을 보고해야 한다.

가상 시스템 최적화 방법

많은 최적화는 시간이 지남에 따라 JVM의 성능을 향상시켰다. 그러나 자바(Java)가 이러한 가상 시스템을 성공적으로 구현한 첫 번째 가상 머신임에도 불구하고 다른 유사한 플랫폼에서도 자주 사용되어 왔다.

적시 컴파일

추가 정보: 적시 컴파일 및 HotSpot(가상 시스템)

초기 JVM은 항상 Java 바이트코드를 해석했다. 이것은 평균 애플리케이션에서 자바 대 C의 경우 10에서 20 사이의 큰 성능 저하를 보였다.[5] 이에 맞서 JIT(Just-in-Time) 컴파일러를 자바 1.1에 도입했다. 컴파일 비용이 높기 때문에, 자바 1.2에 HotSpot이라는 추가 시스템이 도입되었고, 자바 1.3에서는 디폴트가 되었다. 이 프레임워크를 사용하여 Java 가상 머신은 자주 또는 반복적으로 실행되는 핫스팟에 대한 프로그램 성능을 지속적으로 분석한다. 그런 다음 이러한 것들은 최적화를 목표로 하며, 성능 중요도가 낮은 코드에 대한 최소 오버헤드로 고성능 실행을 유도한다.[6][7] 일부 벤치마크는 이 수단에 의해 10배의 속도 증가를 보여 준다.[8] 그러나, 시간 제약으로 인해 컴파일러는 프로그램을 완전히 최적화할 수 없고, 따라서 결과 프로그램은 네이티브 코드 대체 프로그램보다 느리다.[9][10]

적응형 최적화

추가 정보: 적응 최적화

적응 최적화는 컴퓨터 과학에서 현재 실행 프로파일에 근거하여 프로그램의 일부를 동적으로 재구성하는 방법이다. 간단한 구현을 통해 적응형 최적화 도구는 적시 컴파일 및 해석 지침 사이에서 트레이드오프를 할 수 있다. 또 다른 수준에서 적응형 최적화는 로컬 데이터 조건을 이용하여 분기를 최적화하고 인라인 확장을 사용할 수 있다.

또한 HotSpot과 같은 Java 가상 머신은 이전에 JITed되었던 코드를 최적화할 수 있다. 이를 통해 공격적인(그리고 잠재적으로 안전하지 않은) 최적화를 수행하면서도 나중에 코드를 최적화하고 안전한 경로로 돌아갈 수 있다.[11][12]

쓰레기 수거

추가 정보: 가비지 수집(컴퓨터 과학)

1.0과 1.1 자바 가상 머신(JVM)은 마크 스위프 수집기를 사용했는데, 이는 가비지 수집 후 힙을 조각낼 수 있다. 자바 1.2를 시작으로 JVM이 세대 수집기로 바뀌면서 조각 모음 동작이 훨씬 더 잘됐다.[13] 현대의 JVM은 가비지 수집 성능을 더욱 향상시킨 다양한 방법을 사용한다.[14]

기타 최적화 방법

압축 웁스

압축된 Oops를 통해 Java 5.0+는 32비트 참조로 최대 32GB의 힙을 처리할 수 있다. Java는 기본적으로 정렬된 8바이트 객체만 개별 바이트에 대한 액세스를 지원하지 않는다. 이 때문에 힙 참조의 가장 낮은 3비트는 항상 0이 된다. 32비트 참조의 해상도를 8바이트 블록으로 낮추면 주소 지정 가능한 공간을 32GB로 늘릴 수 있다. 이는 자바에서 C++와 같은 일부 언어보다 훨씬 더 많이 참조를 사용하기 때문에 64비트 참조를 사용하는 것에 비해 메모리 사용량을 크게 줄인다. Java 8은 32비트 참조로 최대 64GB를 지원하는 16바이트 정렬과 같은 대형 정렬을 지원한다.[citation needed]

분할 바이트 코드 확인

클래스를 실행하기 전에 Sun JVM은 Java 바이트 코드를 확인한다(바이트코드 검증기 참조). 이 확인은 느리게 수행된다: 클래스의 바이트 코드는 특정 클래스가 로드되고 사용할 준비가 되었을 때만 로드되고 검증되며 프로그램 시작 시에는 검증되지 않는다. 단, 자바 클래스 라이브러리도 정규 자바 클래스이기 때문에 사용할 때도 로딩해야 하므로, 예를 들어 자바 프로그램의 시작 시간이 C++ 프로그램보다 긴 경우가 많다.

자바 플랫폼 마이크로 에디션(J2ME)에서 처음 도입된 분할 시간 검증이라는 이름의 방법이 자바 버전 6 이후 JVM에서 사용되고 있다. Java 바이트 코드의 검증을 두 단계로 분할한다.[15]

  • 디자인 타임 – 소스로부터 바이트 코드로 클래스를 컴파일할 때
  • 런타임 – 클래스를 로드할 때.

실제로 이 방법은 자바 컴파일러가 가지고 있는 클래스 흐름의 지식을 포착하고, 컴파일된 메서드 바이트코드에 클래스 흐름 정보의 개요를 주석을 달아서 작동한다. 이것은 런타임 검증을 눈에 띄게 덜 복잡하게 만들지는 않지만, 일부 단축키를 허용한다.[citation needed]

탈출 분석 및 잠금 조임

추가 정보: 잠금(컴퓨터 과학) 및 이스케이프 분석

자바는 언어 수준에서 멀티스레딩을 관리할 수 있다. 멀티스레딩은 프로그램이 여러 프로세스를 동시에 수행할 수 있도록 해 프로세서나 코어가 여러 개인 컴퓨터 시스템에서 더 빠른 프로그램을 제작하는 방식이다. 또한, 멀티스레드 응용프로그램은 장기간 실행되는 작업을 수행하는 동안에도 입력에 대한 응답성을 유지할 수 있다.

그러나 멀티스레딩을 사용하는 프로그램은 스레드 간에 공유되는 객체를 각별히 주의하여 스레드 중 하나에서 사용할 때 공유된 메서드나 블록에 대한 액세스를 잠글 필요가 있다. 블록이나 객체를 잠그는 것은 관련된 기본 운영 체제 수준 운영의 특성상 시간이 많이 걸리는 작업이다(동일성 제어 및 잠금 세분성 참조).

자바 라이브러리는 둘 이상의 스레드에서 어떤 방법을 사용할지 모르기 때문에 표준 라이브러리는 멀티스레드 환경에서 필요할 때 항상 블록을 잠근다.

Java 6 이전에 가상 머신은 한 번에 두 개의 서로 다른 스레드에 의해 개체가 수정될 위험이 없더라도 프로그램이 요청할 때 항상 개체와 블록을 잠갔다. 예를 들어, 이 경우 로컬이 vector 다른 스레드에 의해 수정되지 않도록 각 추가 작업 전에 잠겼지만(이러한 스레드는 동기화됨), 이 방법은 엄격히 로컬이기 때문에 다음과 같은 필요가 없다. 

공중의 끈 getNames() {      벡터<끈> v = 새로운 벡터<>();      v.덧셈을("Me");      v.덧셈을("너");      v.덧셈을("그녀");      돌아오다 v.토스트링(); }

Java 6부터는 코드 블록과 객체가 필요할 때만 잠기므로 위의 경우 가상 머신이 벡터 객체를 전혀 잠그지 않는다.[16]

버전 6u23부터 자바에는 탈출 분석 지원이 포함되어 있다.[17]

할당개선등록

Java 6 이전까지는 클라이언트 가상 머신에서 레지스터의 할당이 매우 원시적이었다(블록 전체에 걸쳐 있지 않음). x86s처럼 프로세서 레지스터가 더 적은 CPU 설계에서 문제가 있었다. 작업에 사용할 수 있는 레지스터가 더 이상 없을 경우 컴파일러는 레지스터에서 메모리(또는 등록할 메모리)로 복사해야 하므로 시간이 걸린다(등록기는 접근 속도가 상당히 빠름). 그러나 서버 가상 머신은 컬러그래프 할당자를 사용했으며 이 문제는 없었다.

Sun의 JDK 6에서는 레지스터 할당 최적화가 도입되었다.[18] 그런 다음 블록 간에 동일한 레지스터를 사용할 수 있게 되어 메모리에 대한 액세스가 줄어들었다. 이로 인해 일부 벤치마크에서 약 60%의 실적 상승이 보고되었다.[19]

클래스 데이터 공유

클래스 데이터 공유(Class data sharing, 일명 CDS by Sun)는 자바 애플리케이션의 시작 시간을 줄이고 메모리 설치 공간도 줄이는 메커니즘이다. JRE가 설치되면 설치자는 시스템 JAR 파일(rt.jar라고 하는 모든 Java 클래스 라이브러리를 저장하는 JAR 파일)의 클래스 세트를 개인 내부 표현으로 로드하고, 그러한 표현을 "공유 보관"이라고 하는 파일로 덤프한다. 이후의 JVM 호출 동안, 이 공유 아카이브는 메모리 맵이 되어 해당 클래스를 로드하는 비용을 절감하고 이러한 클래스에 대한 JVM 메타데이터의 대부분을 여러 JVM 프로세스 간에 공유할 수 있다.[20]

이에 상응하는 창업시간의 향상은 소규모 프로그램일수록 더 뚜렷하다.[21]

성능 개선 이력

추가 정보: Java 버전 기록

여기에 열거된 개선사항과는 별도로, Java의 각 릴리스는 JVM과 Java API(응용 프로그래밍 인터페이스)에 많은 성능 향상을 도입했다.

JDK 1.1.6: 첫 번째 적시 컴파일(Symantec의 JIT 컴파일러)[2][22]

J2SE 1.2: 세대 수집기 사용.

J2SE 1.3: HotSpot에 의한 적시 컴파일.

J2SE 1.4: 1.3 버전과 1.4 버전 사이의 성능 향상에 대한 Sun 개요는 여기를 참조하십시오.

Java SE 5.0: 클래스 데이터 공유[23]

Java SE 6:

기타 개선 사항:

  • Java OpenGL Java 2D 파이프라인 속도 향상[24]
  • Java 2D 성능도 Java 6에서[25] 크게 향상됨

또한 'Java 5와 Java 6 사이의 성능 향상에 대한 Sun 개요'[26]를 참조하십시오.

Java SE 6 업데이트 10

  • Java Quick Starter는 디스크 캐시에 OS 시작 시 JRE 데이터의 일부를 미리 로드하여 애플리케이션 시작 시간을 단축한다.[27]
  • JRE가 설치되지 않았을 때 웹에서 접속한 애플리케이션을 실행하는 데 필요한 플랫폼의 일부가 이제 먼저 다운로드된다. 전체 JRE는 12MB로 일반적인 스윙 애플리케이션은 4MB만 다운로드하면 시작할 수 있다. 그런 다음 나머지 부품은 백그라운드에서 다운로드한다.[28]
  • Windows(윈도우)의 그래픽 성능은 기본적으로 Direct3D를 광범위하게 사용함으로써 향상되었으며,[29] GPU(그래픽 처리 장치)에서는 쉐이더를 사용하여 복잡한 Java 2D 작업을 가속화하였다.[30]

자바 7

Java 7에 대해 몇 가지 성능 개선이 발표되었다: Java 6 또는 Java 7의 업데이트에 대해 향후 성능 개선이 계획된다.[31]

  • 다빈치 머신(다중 언어 가상 머신)[32]에서 현재 수행 중인 프로토타이핑 작업에 이어 동적 프로그래밍 언어에 대한 JVM 지원 제공
  • 멀티 코어 프로세서에서 병렬 컴퓨팅을 관리하여 기존 동시성 라이브러리 [33][34]향상
  • JVM이 클라이언트와 서버J를 모두 사용하도록 허용IT는 계층화된 컴파일이라고 하는 방법으로 동일한 세션에서 컴파일한다.[35]
    • 시작 시 클라이언트를 사용할 수 있음(시작 시와 소규모 애플리케이션에 적합하기 때문에),
    • 서버는 응용프로그램의 장기 실행에 사용될 것이다(이것은 클라이언트 컴파일러를 능가하기 때문이다).
  • 기존의 동시 저일시 가비지 수집기(CMS(Concurrent Mark-Sweep) 수집기를 가비지 퍼스트(G1)라는 새 수집기로 교체하여 시간이 지남에 따라 일관된 일시 중지를 보장한다.[36][37]

다른 언어와 비교

자바 프로그램과 C++와 같은 다른 언어로 작성된 동등한 프로그램의 성능을 객관적으로 비교하려면 동일한 작업을 완료하는 프로그램을 비교하는 신중하고 신중하게 구성된 벤치마크를 필요로 한다. 자바 바이트코드 컴파일러의 대상 플랫폼은 자바 플랫폼이며, 바이트코드는 JVM에 의해 기계 코드로 해석되거나 컴파일된다. 다른 컴파일러들은 거의 항상 특정 하드웨어와 소프트웨어 플랫폼을 목표로 하며, 실행[citation needed] 중에도 거의 변하지 않는 기계 코드를 생성한다. 매우 다르고 비교하기 어려운 시나리오는 정적 대 동적 컴파일과 재컴파일, 런타임 환경에 대한 정확한 정보의 가용성 등 이 두 가지 접근방식에서 발생한다.

Java는 종종 Java 가상 머신에 의해 런타임에 Just-in-time으로 컴파일되지만, C++와 같이 미리 컴파일될 수도 있다. 정시에 컴파일할 때, The Computer Language Benchmarks Game의 마이크로 벤치마크는 그 성능에 대해 다음과 같이 나타낸다.[38]

  • C 또는 C++[39]와 같은 컴파일된 언어보다 느리게,
  • 다른 [40]Just-in-time 컴파일된 언어와 유사하게,
  • Perl, Ruby, PHP, Python과 같은 효과적인 네이티브 코드 컴파일러(JIT 또는 AOT)가 없는 언어보다 훨씬 빠르다.[41]

프로그램 속도

벤치마크는 종종 수적으로 집약적인 소규모 프로그램의 성능을 측정한다. 몇몇 희귀한 실생활 프로그램에서는 자바가 C를 능가한다. Jake2의 벤치마크(원래 GPL C코드를 번역해 자바어로 쓴 지진2의 클론)가 그 한 예다. Java 5.0 버전은 C 버전보다 일부 하드웨어 구성에서 더 우수한 성능을 발휘한다.[42] 데이터가 어떻게 측정되었는지는 명시되어 있지 않지만(예를 들어, 현재 C 컴파일러가 더 나은 최적화를 달성할 수 있기 때문에 좋지 않은 것으로 간주될 수 있는 1997년에 컴파일한 Sevin II 실행 파일이 사용된 경우), 동일한 Java 소스 코드가 어떻게 VM을 업데이트하는 것만으로 엄청난 속도 향상을 이룰 수 있는지, what are nothing anything thanksuffic하게 된다.그것은 100% 정적인 접근이다.

다른 프로그램의 경우, C++ 상대 프로그램이 자바 등가 프로그램보다 훨씬 더 빨리 실행될 수 있으며, 보통 그렇게 한다. 2011년 구글이 실시한 벤치마크에서 C++와 자바 사이의 인자가 10으로 나타났다.[43] 다른 극단에서는 2012년에 3D 모델링 알고리즘으로 수행된 학술 벤치마크에서 자바 6 JVM이 Windows에서 C++보다 1.09배에서 1.91배 느리다는 것을 보여주었다.[44]

Java 및 유사한 언어에서 가능한 일부 최적화는 C++[45]의 특정 상황에서 가능하지 않을 수 있다.

  • C 스타일 포인터 사용은 포인터를 지원하는 언어의 최적화를 방해할 수 있다.
  • 예를 들어, C++ 컴파일러는 포인터로 인해 주어진 코드 블록에서 객체가 수정될 것인지 항상 알 수 없기 때문에 탈출 분석 방법의 사용은 C++로 제한된다.[note 1]
  • 자바는 C++의 추가 가상 테이블 조회로 인해 C++가 파생된 가상 메서드에 액세스할 수 있는 것보다 더 빠르게 파생된 인스턴스 메서드에 액세스할 수 있다. 그러나 C++의 비가상 방법은 v-table 성능 병목 현상을 겪지 않기 때문에 Java와 유사한 성능을 보인다.

JVM은 프로세서별 최적화 또는 인라인 확장도 수행할 수 있다. 그리고, 이미 컴파일되거나 인라인된 코드의 최적화를 해제하는 능력은 때때로 외부 라이브러리 기능이 관련되었을 때 정적으로 타이핑된 언어에 의해 수행되는 것보다 더 공격적인 최적화를 수행할 수 있게 한다.[46][47]

Java와 C++ 사이의 마이크로벤치마크 결과는 어떤 작업을 비교하느냐에 따라 크게 달라진다. 예를 들어, Java 5.0과 비교할 때:

메모들
  1. ^ 이러한 성격의 경합은 사용자 지정 할당자와 같은 고급 방법을 채택하여 Java가 은폐 및 캡슐화하도록 설계된 저수준 코딩 복잡성의 종류를 정밀하게 이용함으로써 소스 코드 수준의 C++ 프로그램에서 완화될 수 있다. 그러나 이러한 접근법은 pr을 채택하거나 최소한 예상하는 동안 채택되지 않으면 거의 실용적이지 않다(또는 최소한 예상).ogram은 1차 개발 중에 있다.

멀티 코어 성능

멀티 코어 시스템에서 Java 애플리케이션의 확장성과 성능은 객체 할당 속도에 의해 제한된다. 이러한 효과를 "배분벽"이라고 부르기도 한다.[54] 그러나 실제로 현대의 가비지 수집기 알고리즘은 여러 코어를 사용하여 가비지 수집을 수행하는데, 이것은 어느 정도 이 문제를 완화시킨다. 일부 가비지 수집기는 초당 1기가바이트 이상의 할당률을 유지하는 것으로 보고되며,[55] 수백 개의 CPU 코어로 확장하는 데 문제가 없고 수백 GB의 힙 사이즈가 있는 자바 기반 시스템도 존재한다.[56]

자바에서의 자동 메모리 관리는 어떤 종류의 쓰레기 수집 없이는 구현이 불가능하거나 극도로 어려운 고정되지 않고 불변의 데이터 구조를 효율적으로 사용할 수 있게 해준다.[citation needed] 자바는 표준 라이브러리에 있는 Java.util.concurrent 패키지에 있는 그러한 수준 높은 구조를 많이 제공하는 반면, 역사적으로 C나 C++와 같은 고성능 시스템에 사용되는 많은 언어들은 여전히 그 구조가 부족하다.[citation needed]

시작시간

많은 클래스(그리고 플랫폼 클래스 라이브러리의 모든 클래스 중 첫 번째 클래스)를 로드해야 사용하기 때문에 자바 시작 시간이 C, C++, Perl 또는 Python을 포함한 여러 언어보다 훨씬 느린 경우가 많다.

비슷한 인기 런타임과 비교했을 때, Windows 컴퓨터에서 실행되는 작은 프로그램의 경우, 시작 시간은 Mono와 비슷하고 에 비해 약간 느린 것으로 보인다.넷.[57]

시작 시간의 상당 부분은 JVM 초기화나 클래스 로딩(rt.jar 클래스 데이터 파일만 40MB이고 JVM은 이 빅 파일에서 많은 데이터를 찾아야 한다)[27]보다는 입출력(IO) 바인딩 작업에 기인하는 것으로 보인다. 일부 테스트에서는 새로운 분할 바이트코드 검증 방식이 클래스 로드를 약 40% 향상시켰지만 대형 프로그램에서는 5%의 시작 향상만 실현한 것으로 나타났다.[58]

작은 개선에도 불구하고, Java 플랫폼 데이터 로딩은 실제 프로그램 운영의 여러 배에 달하는 부하를 나타낼 수 있기 때문에 간단한 조작을 수행한 후 종료하는 소규모 프로그램에서는 더욱 눈에 띈다.

Java SE 6 업데이트 10부터 Sun JRE는 OS 시작 시 클래스 데이터를 미리 로드하여 디스크가 아닌 디스크 캐시에서 데이터를 가져오는 Quick Starter와 함께 제공된다.

Excelsior JET는 다른 쪽에서 문제에 접근한다. Startup Optimizer는 애플리케이션 시작 시 디스크에서 읽어야 하는 데이터 양을 줄이고 읽기를 순차적으로 만든다.

2004년 11월, 「JVM 스타트 오버헤드를 부담하지 않고 커맨드 라인에서 자바 프로그램을 실행하는 클라이언트·프로토콜·서버」가 공개되었다.[59] 스크립트가 JVM 시작 오버헤드 없이 하나 이상의 Java 애플리케이션을 실행하는 데몬으로 사용하는 옵션을 처음으로 도입. 네일건 데몬은 불안정하다: "모든 프로그램은 서버와 동일한 권한으로 실행된다." 다중이용자 보안이 필요한 곳에서 네일건은 특별한 예방책이 없으면 부적절하다. 애플리케이션별 JVM 시작이 리소스 사용을 지배하는 스크립트는 1-2단계의 런타임 성능 향상 순서를 참조하십시오.[60]

메모리 사용

다음과 같은 이유로 자바 메모리 사용이 C++의 메모리 사용량보다 훨씬 높다.

  • Java의 각 객체에는 8바이트의 오버헤드가 있고 각 어레이에는[61] 12바이트의 오버헤드가 있다. 만약 물체의 크기가 8바이트의 배수가 아니라면, 8의 다음 배수로 반올림된다. 이것은 하나의 바이트 필드를 가진 물체가 16바이트를 차지하고 4바이트의 참조가 필요하다는 것을 의미한다. 또한 C++는 클래스가 직접 또는 간접적으로 가상 기능을 선언하는 모든 개체에 포인터(일반적으로 4 또는 8바이트)를 할당한다.[62]
  • 주소 산술의 부족은 촘촘한 간격의 구조와 XOR 링크 목록과 같은 메모리 효율적인 용기를 현재 불가능하게 만든다(OpenJDK Valhalla 프로젝트는 포인터 산술의 도입을 목표로 하는 것은 아니지만, 이는 쓰레기 수거 환경에서는 할 수 없다).
  • malloc 및 new와는 달리, 힙 크기가 증가함에 따라 가비지 수집의 평균 성능 오버헤드는 무증상적으로 0(더 정확히 말하면, 하나의 CPU 사이클)에 근접한다.[63]
  • 자바 클래스 라이브러리의 일부는 프로그램을 실행하기 전에 로드되어야 한다(적어도 프로그램 내에서 사용되는 클래스).[64] 이는 소규모 애플리케이션의 상당한 메모리 오버헤드로 이어진다.[citation needed]
  • 자바 바이너리와 네이티브 재컴파일 모두 일반적으로 메모리에 저장된다.
  • 가상 시스템은 상당한 메모리를 사용한다.
  • 자바에서는 B와 C의 할당된 인스턴스에 대한 참조를 사용하여 복합 객체(B와 C의 인스턴스를 사용하는 클래스 A)가 생성된다. C++에서 B 및/또는 C의 인스턴스가 A 내에 존재할 경우 이러한 유형의 참조에 대한 메모리 및 성능 비용을 피할 수 있다.

대부분의 경우, C++ 애플리케이션은 Java 가상 머신의 큰 오버헤드, 클래스 로딩 및 자동 메모리 크기 조정으로 인해 동등한 Java 애플리케이션보다 더 적은 메모리를 소비하게 된다. 언어와 런타임 환경 사이에서 메모리가 중요한 요소인 프로그램의 경우 비용/편익 분석이 필요하다.

삼각함수

자바에는 기초 하드웨어 구현에 해당하지 않을 수 있는 수학 연산 결과에 대한 엄격한 사양이 있기 때문에 삼각함수의 성능은 C에 비해 좋지 않다.[65] x87 부동소수점 서브셋에서 1.4 이후 자바는 소프트웨어에서 sin과 cos에 대한 인수를 줄여 범위를 벗어난 값에 대해 큰 성능 적중을 일으킨다.[66][67][clarification needed] JDK(11 이상)는 JDK 8에 비해 삼각함수 평가 속도에 상당한 진전이 있다.[68]

자바 네이티브 인터페이스

Java Native Interface는 높은 오버헤드를 발생시켜 JVM에서 실행되는 코드와 네이티브 코드 사이의 경계를 넘어야 하는 비용이 많이 든다.[69][70] JNA(Java Native Access)는 JNI나 네이티브 코드 없이 Java 코드만으로 Java 프로그램에 네이티브 공유 라이브러리(Windows의 DLLs)에 쉽게 접근할 수 있도록 한다. 이 기능은 윈도 플랫폼/인보크 및 파이썬의 ctypes와 견줄 만하다. 코드 생성 없이 런타임에 액세스가 동적이다. 하지만 그것은 비용이 들고, JNA는 보통 JNI보다 느리다.[71]

사용자 인터페이스

Swing은 순수한 Java 2D API에 위젯 렌더링을 위임하기 때문에 기본 위젯 툴킷보다 느리게 인식되어 왔다. 그러나 운영 체제의 기본 GUI 라이브러리에 렌더링을 위임하는 Swing과 표준 위젯 툴킷의 성능을 비교한 벤치마크에서는 명확한 승자가 나타나지 않으며, 결과는 컨텍스트와 환경에 따라 크게 달라진다.[72] 또한 스윙을 대체하기 위한 새로운 자바FX 프레임워크는 스윙의 본질적인 문제를 많이 다룬다.

고성능 컴퓨팅에 사용

일부 사람들은 Java의 고성능 컴퓨팅(HPC) 성능이 컴퓨팅 집약적인 벤치마크에서 Fortran과 유사하지만, JVM은 그리드 컴퓨팅 네트워크에서 집중적인 통신을 수행하기 위한 확장성 문제를 여전히 가지고 있다고 생각한다.[73]

그러나 자바어로 작성된 고성능 컴퓨팅 애플리케이션은 벤치마크 대회에서 우승했다. 2008년과 [74]2009년에는 Apache Hadoop(Java로 작성된 오픈 소스 고성능 컴퓨팅 프로젝트) 기반 클러스터가 테라바이트와 페타바이트의 정수를 가장 빠르게 정렬할 수 있었다.[75][76] 그러나 경쟁 시스템의 하드웨어 설정은 고정되지 않았다.[77][78]

프로그래밍 경연대회에서

자바의 프로그램은 컴파일된 다른 언어의 프로그램보다 느리게 시작된다.[79][80] 따라서 일부 온라인 심판 시스템, 특히 중국 대학들이 주관하는 시스템은 자바 프로그램이[81][82][83][84][85] 자바를 사용하는 참가자들에게 공정하게 적용되기 위해 더 긴 시간 제한을 사용한다.

참고 항목

참조

  1. ^ "Java versus C++ benchmarks".
  2. ^ a b "Symantec's Just-In-Time Java Compiler To Be Integrated Into Sun JDK 1.1".
  3. ^ "Short Take: Apple licenses Symantec's just-in-time compiler". cnet.com. May 12, 1998. Retrieved November 15, 2015.
  4. ^ "Java gets four times faster with new Symantec just-in-time compiler".
  5. ^ http://www.shudo.net/jit/perf/
  6. ^ Kawaguchi, Kohsuke (March 30, 2008). "Deep dive into assembly code from Java". Archived from the original on April 2, 2008. Retrieved April 2, 2008.
  7. ^ "Fast, Effective Code Generation in a Just-In-Time Java Compiler" (PDF). Intel Corporation. Retrieved June 22, 2007.
  8. ^ 이 기사는 해석 모드와 Hotspot 사이의 성능 이득이 10배 이상에 달한다는 것을 보여준다.
  9. ^ C, C# 및 Java의 숫자 성능
  10. ^ 웨이백 머신에 보관된 C, C++, Java 및 C# 프로그래밍 언어 간의 알고리즘 성능 비교
  11. ^ "The Java HotSpot Virtual Machine, v1.4.1". Sun Microsystems. Retrieved April 20, 2008.
  12. ^ Nutter, Charles (January 28, 2008). "Lang.NET 2008: Day 1 Thoughts". Retrieved January 18, 2011. Deoptimization is very exciting when dealing with performance concerns, since it means you can make much more aggressive optimizations...knowing you'll be able to fall back on a tried and true safe path later on
  13. ^ IBM DeveloperWorks 라이브러리
  14. ^ 예를 들어, 일시 정지 기간은 현재 덜 눈에 띈다. 예를 들어 Java로 쓰여진 Jeak2의 이 Jeak2를 보라.
  15. ^ "New Java SE 6 Feature: Type Checking Verifier". Java.net. Retrieved January 18, 2011.[영구적 데드링크]
  16. ^ Brian Goetz (October 18, 2005). "Java theory and practice: Synchronization optimizations in Mustang". IBM. Retrieved January 26, 2013.
  17. ^ "Java HotSpot Virtual Machine Performance Enhancements". Oracle Corporation. Retrieved January 14, 2014. Escape analysis is a technique by which the Java Hotspot Server Compiler can analyze the scope of a new object's uses and decide whether to allocate it on the Java heap. Escape analysis is supported and enabled by default in Java SE 6u23 and later.
  18. ^ 버그 리포트: 새 레지스터 할당자로, Mustang(JDK 6) b59에 고정됨
  19. ^ 무스탕의 HotSpot Client는 58% 빨라졌다! 2012년 3월 5일 Osvaldo Pinali Doderlein's 블로그(java.net)에 보관
  20. ^ java.sun.com의 클래스 데이터 공유
  21. ^ Artima 개발자 Java Buzz Forum에서 JDK 1.5.0의 클래스 데이터 공유
  22. ^ Mckay, Niali. "Java gets four times faster with new Symantec just-in-time compiler".
  23. ^ 1.4 버전과 5.0 버전 사이의 성능 향상에 대한 Sun 개요.
  24. ^ STR-Crazier: Mustang의 성능 향상 2007년 1월 5일 Chris Campbell's 블로그의 Wayback Machine(java.net)에 보관
  25. ^ JFreeChart 애플리케이션의 Java 5.0에서 6으로 약 60% 향상된 성능을 보여주는 벤치마크를 보려면 여기를 참조하십시오.
  26. ^ Java SE 6 성능 백서(http://java.sun.com
  27. ^ a b Haase, Chet (May 2007). "Consumer JRE: Leaner, Meaner Java Technology". Sun Microsystems. Retrieved July 27, 2007. At the OS level, all of these megabytes have to be read from disk, which is a very slow operation. Actually, it's the seek time of the disk that's the killer; reading large files sequentially is relatively fast, but seeking the bits that we actually need is not. So even though we only need a small fraction of the data in these large files for any particular application, the fact that we're seeking all over within the files means that there is plenty of disk activity.
  28. ^ Haase, Chet (May 2007). "Consumer JRE: Leaner, Meaner Java Technology". Sun Microsystems. Retrieved July 27, 2007.
  29. ^ Haase, Chet (May 2007). "Consumer JRE: Leaner, Meaner Java Technology". Sun Microsystems. Retrieved July 27, 2007.
  30. ^ Campbell, Chris (April 7, 2007). "Faster Java 2D Via Shaders". Archived from the original on June 5, 2011. Retrieved January 18, 2011.
  31. ^ Haase, Chet (May 2007). "Consumer JRE: Leaner, Meaner Java Technology". Sun Microsystems. Retrieved July 27, 2007.
  32. ^ "JSR 292: Supporting Dynamically Typed Languages on the Java Platform". jcp.org. Retrieved May 28, 2008.
  33. ^ Goetz, Brian (March 4, 2008). "Java theory and practice: Stick a fork in it, Part 2". Retrieved March 9, 2008.
  34. ^ Lorimer, R.J. (March 21, 2008). "Parallelism with Fork/Join in Java 7". infoq.com. Retrieved May 28, 2008.
  35. ^ "New Compiler Optimizations in the Java HotSpot Virtual Machine" (PDF). Sun Microsystems. May 2006. Retrieved May 30, 2008.
  36. ^ Humble, Charles (May 13, 2008). "JavaOne: Garbage First". infoq.com. Retrieved September 7, 2008.
  37. ^ Coward, Danny (November 12, 2008). "Java VM: Trying a new Garbage Collector for JDK 7". Archived from the original on December 8, 2011. Retrieved November 15, 2008.
  38. ^ "Computer Language Benchmarks Game". benchmarksgame.alioth.debian.org. Archived from the original on January 25, 2015. Retrieved June 2, 2011.
  39. ^ "Computer Language Benchmarks Game". benchmarksgame.alioth.debian.org. Archived from the original on January 13, 2015. Retrieved June 2, 2011.
  40. ^ "Computer Language Benchmarks Game". benchmarksgame.alioth.debian.org. Archived from the original on January 10, 2015. Retrieved June 2, 2011.
  41. ^ "Computer Language Benchmarks Game". benchmarksgame.alioth.debian.org. Archived from the original on January 2, 2015. Retrieved June 2, 2011.
  42. ^ : 260/250 프레임/s 대 245 프레임/s(벤치마크 참조)
  43. ^ Hundt, Robert. "Loop Recognition in C++/Java/Go/Scala" (PDF). Scala Days 2011. Stanford, California. Retrieved March 23, 2014.
  44. ^ L. Gherardi; D. Brugali; D. Comotti (2012). "A Java vs. C++ performance evaluation: a 3D modeling benchmark" (PDF). University of Bergamo. Retrieved March 23, 2014. Using the Server compiler, which is best tuned for long-running applications, have instead demonstrated that Java is from 1.09 to 1.91 times slower(...)In conclusion, the results obtained with the server compiler and these important features suggest that Java can be considered a valid alternative to C++
  45. ^ Lewis, J.P.; Neumann, Ulrich. "Performance of Java versus C++". Computer Graphics and Immersive Technology Lab, University of Southern California.
  46. ^ "The Java HotSpot Performance Engine: Method Inlining Example". Oracle Corporation. Retrieved June 11, 2011.
  47. ^ Nutter, Charles (May 3, 2008). "The Power of the JVM". Retrieved June 11, 2011. What happens if you've already inlined A's method when B comes along? Here again the JVM shines. Because the JVM is essentially a dynamic language runtime under the covers, it remains ever-vigilant, watching for exactly these sorts of events to happen. And here's the really cool part: when situations change, the JVM can deoptimize. This is a crucial detail. Many other runtimes can only do their optimization once. C compilers must do it all ahead of time, during the build. Some allow you to profile your application and feed that into subsequent builds, but once you've released a piece of code it's essentially as optimized as it will ever get. Other VM-like systems like the CLR do have a JIT phase, but it happens early in execution (maybe before the system even starts executing) and doesn't ever happen again. The JVM's ability to deoptimize and return to interpretation gives it room to be optimistic...room to make ambitious guesses and gracefully fall back to a safe state, to try again later.
  48. ^ "Microbenchmarking C++, C#, and Java: 32-bit integer arithmetic". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.
  49. ^ "Microbenchmarking C++, C#, and Java: 64-bit double arithmetic". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.
  50. ^ "Microbenchmarking C++, C#, and Java: File I/O". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.
  51. ^ "Microbenchmarking C++, C#, and Java: Exception". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.
  52. ^ "Microbenchmarking C++, C#, and Java: Array". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.
  53. ^ "Microbenchmarking C++, C#, and Java: Trigonometric functions". Dr. Dobb's Journal. July 1, 2005. Retrieved January 18, 2011.
  54. ^ 이쟈오, 진시, 카이정, 하이촨 왕, 하이보 린, 링샤오, 할당벽: 신흥 멀티 코어 플랫폼에 대한 자바 애플리케이션의 제한 요소, 객체 지향 프로그래밍 시스템 언어 및 애플리케이션에 관한 제24회 ACM SIGLAN 회의의 2009년.
  55. ^ C4: Continuous Concurrent Compacting Collector
  56. ^ 아줄은 768 코어 머신으로 자바를 괴롭힌다.
  57. ^ "Benchmark start-up and system performance for .Net, Mono, Java, C++ and their respective UI". September 2, 2010.
  58. ^ "How fast is the new verifier?". 7 February 2006. Archived from the original on 16 May 2006. Retrieved 9 May 2007.
  59. ^ 네일건
  60. ^ 네일건 배경 페이지는 "베스트 케이스 시나리오" 속도가 33배(대본 "Hello, World!" 프로그램, 즉 단기 실행 프로그램)로 향상되었음을 보여준다.
  61. ^ http://www.javamex.com/tutorials/memory/object_memory_usage.shtml
  62. ^ "Archived copy". Archived from the original on 21 February 2008. Retrieved 22 June 2009.CS1 maint: 제목으로 보관된 복사본(링크)
  63. ^ https://www.youtube.com/watch?v=M91w0SBZ-wc : Java 가비지 컬렉션 이해 - JavaOne에서 Gil Tene의 강연
  64. ^ http://www.tommti-systems.de/go.html?http:///www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html
  65. ^ "Math (Java Platform SE 6)". Sun Microsystems. Retrieved June 8, 2008.
  66. ^ Gosling, James (July 27, 2005). "Transcendental Meditation". Archived from the original on August 12, 2011. Retrieved June 8, 2008.
  67. ^ W. Cowell-Shah, Christopher (January 8, 2004). "Nine Language Performance Round-up: Benchmarking Math & File I/O". Archived from the original on October 11, 2018. Retrieved June 8, 2008.
  68. ^ S. V. Chekanov, G. Gavalian, N. A. Graf, Jas4pp - 물리 및 검출기 연구를 위한 데이터 분석 프레임워크, (1987), (https://arxiv.org/abs/2011.05329)) ANL-HEP-164101, SLAC-PUB-17569
  69. ^ Wilson, Steve; Jeff Kesselman (2001). "JavaTM Platform Performance: Using Native Code". Sun Microsystems. Retrieved February 15, 2008.
  70. ^ Kurzyniec, Dawid; Vaidy Sunderam. "Efficient Cooperation between Java and Native Codes - JNI Performance Benchmark" (PDF). Archived from the original (PDF) on 14 February 2005. Retrieved 15 February 2008.
  71. ^ "How does JNA performance compare to custom JNI?". Sun Microsystems. Retrieved December 26, 2009.[영구적 데드링크]
  72. ^ Igor, Križnar (10 May 2005). "SWT Vs. Swing Performance Comparison" (PDF). cosylab.com. Archived from the original (PDF) on 4 July 2008. Retrieved 24 May 2008. It is hard to give a rule-of-thumb where SWT would outperform Swing, or vice versa. In some environments (e.g., Windows), SWT is a winner. In others (Linux, VMware hosting Windows), Swing and its redraw optimization outperform SWT significantly. Differences in performance are significant: factors of 2 and more are common, in either direction
  73. ^ Brian Amedro; Vladimir Bodnartchouk; Denis Caromel; Christian Delbe; Fabrice Huet; Guillermo L. Taboada (August 2008). "Current State of Java for HPC". INRIA. Retrieved September 9, 2008. We first perform some micro benchmarks for various JVMs, showing the overall good performance for basic arithmetic operations(...). Comparing this implementation with a Fortran/MPI one, we show that they have similar performance on computation intensive benchmarks, but still have scalability issues when performing intensive communications.
  74. ^ Owen O'Malley - Yahoo! Grid Computing Team (July 2008). "Apache Hadoop Wins Terabyte Sort Benchmark". Archived from the original on 15 October 2009. Retrieved 21 December 2008. This is the first time that either a Java or an open source program has won.
  75. ^ "Hadoop Sorts a Petabyte in 16.25 Hours and a Terabyte in 62 Seconds". CNET.com. May 11, 2009. Archived from the original on May 16, 2009. Retrieved September 8, 2010. The hardware and operating system details are:(...)Sun Java JDK (1.6.0_05-b13 and 1.6.0_13-b03) (32 and 64 bit)
  76. ^ "Hadoop breaks data-sorting world records". CNET.com. May 15, 2009. Retrieved September 8, 2010.
  77. ^ Chris Nyberg; Mehul Shah. "Sort Benchmark Home Page". Retrieved November 30, 2010.
  78. ^ Czajkowski, Grzegorz (November 21, 2008). "Sorting 1PB with MapReduce". Retrieved December 1, 2010.
  79. ^ "Archived copy". Archived from the original on 18 October 2010. Retrieved 21 June 2010.CS1 maint: 제목으로 보관된 복사본(링크)
  80. ^ http://acm.timus.ru/help.aspx?topic=java&locale=en
  81. ^ http://acm.pku.edu.cn/JudgeOnline/faq.htm#q11
  82. ^ "Archived copy". Archived from the original on June 29, 2010. Retrieved May 25, 2010.CS1 maint: 제목으로 보관된 복사본(링크)
  83. ^ http://www.codechef.com/wiki/faq#How_does_the_time_limit_work
  84. ^ "Archived copy". Archived from the original on 19 February 2012. Retrieved 13 November 2011.CS1 maint: 제목으로 보관된 복사본(링크)
  85. ^ http://poj.org/faq.htm#q9

외부 링크