왜 사람들은 여전히 ​​Java가 느리다고 말합니까? [닫은]

SO와 다른 곳에서 오랫동안 자바는 느리다는 명성을 가지고 있습니다. 에서 농담 에 많은 의견 질문과 답변에서, 사람들은 여전히 자바가 느린 유일하게 90 년대의 그것과 경험을 바탕으로 믿습니다.

이것은 내 문제입니다. 사람들이 Java가 느리다고 믿는 이유를 대부분 반증했습니다 . 작은 것 외에도 Java는 매우 빠릅니다.

그렇다면 왜 사람들은 여전히 ​​Java가 빠르다고 믿지 않습니까? C / C ++가 아닌 것은 느리다는 것이 그들의 사고 방식의 일부입니까? 사람들이 시간이 지남에 따라 확인하지 않기 때문입니까? 사람들이 편향되어 있기 때문입니까?

응용 프로그램입니다. 아시다시피, 우리 는 몇 번이고 입증 된 시나리오에서 Java 코드가 C, C ++, Lisp, VB6 또는 JavaScript와 같은 소위 "성능적인"언어의 성능을 충족 시키거나 능가 할 수 있음을 증명했습니다 . 그리고 그러한 증거가 제시 될 때, 제정신의 열린 마음을 가진 상대는 머리를 부끄러워하고 다시는 그런 비방을 퍼 뜨리지 않을 것을 약속합니다.

...하지만 Eclipse, NetBeans 또는 Guiffy를 실행하거나 브라우저에서 Java 지원을 활성화하거나 좋아하는 피처 폰에서 앱을 실행하려고 시도합니다. 그리고 그들은 그것이 반응하기를 기다립니다 ...

... 그리고 기다리다 ...

... 그리고 기다리다 ...



... 그리고 기다리다 ...







... 그리고 기다리다 ...











... 그리고 ...




... 나는 다시는하지 않겠다고 약속 한 것 ? 죄송합니다.

이 질문은 잘못된 전제에서 작동합니다. 여기서 Java는 여전히 느립니다. 큰 데이터 세트에 대해 계산량이 많은 알고리즘이 중요합니다. 물론, 이들은 C / C ++ 코드와 동등한 수준으로 최적화 될 수 있지만 모듈 성과 일반성을 희생해야합니다. 효율적인 C ++ 코드는 범용 라이브러리로 일반적이고 사용 가능하도록 설계 될 수 있습니다. 자바 코드는 할 수 없습니다. Array.sort모든 기본 유형에 대해 서로 다른 구현을 사용하고 객체 변형이 C ++의 일반보다 훨씬 느리게 최적화 된 고도로 최적화 된 방법을 살펴보십시오. sort이러한 객체는 동등 비교를 동적으로 전달해야하기 때문입니다.

물론, 핫스팟 엔진에 의해 수행되는 시간 최적화는 실제로 이러한 가상 호출의 대상을 예측하고 인라인을 시도 할 수 있습니다. 그러나 이것은 여전히 C ++의 sort메소드 내에서 전달되는 직접 인라인 호출보다 느립니다 .

전직 동료는 템플릿 C ++ 구현과 객체 지향 Java 구현 으로 거대한 데이터 세트 ( 동적 형태를 사용한 q- 그램 계수) 에 대한 문제의 비교 벤치 마크를 수행했습니다. 자바 코드는 C ++ 코드보다 훨씬 느리다.

물론 이것은 사과를 오렌지와 비교하는 것입니다. 그러나 요점은 Java 구현이 라이브러리에 필요한 모듈화 정도를 고려할 때 성능 측면에서 최상의 구현이었으며 C ++ 구현도 마찬가지였습니다.

불행히도 벤치 마크 데이터는 무료로 제공되지 않지만 런타임 추상화의 오버 헤드를 비교할 때 비슷한 수치를 발견했습니다. 예를 들어 Scott Meyers는 C의 일반 함수 오버 헤드에 대해 Effective STL로 작성 qsort합니다.

C ++의 정렬은 속도와 관련하여 거의 항상 C의 qsort를 부끄럽게합니다. […] 런타임시 sort는 비교 함수를 인라인 호출합니다. qsort는 포인터를 통해 비교 함수를 호출합니다. […] 백만 배의 벡터에 대한 테스트에서 [정렬]은 670 % 더 빠르게 달렸습니다.

일부 응용 프로그램에서는 느리기 때문에 ... 데스크톱 응용 프로그램은 처음부터 응답해야하며 시작 오버 헤드는 느리게 계산됩니다.

반면에 서버를 실행하면 약간의 열이 발생하더라도 (JIT 분석 및 컴파일) 중요하지 않습니다. 블루 문에서 한 번만 수행하므로 대부분 느리게 고려할 수 없습니다.

사람들이 처음 만났을 때 느 렸기 때문이라고 말하고 싶습니다. 이를 바탕으로 인상을주었습니다. 그 인상은 그들이 그것을 사용하지 않으면 변하지 않을 것이고, 그들은 그 인상 때문에 그것을 사용하지 않습니다-그것은 악순환입니다.

나는 Java가 느리다는 인상을 받았다. 나는 이제 다른 언어로 옮겼으며 그 이후로 Java에 대한 노출이 극도로 제한되었습니다. 결과적으로 제 의견은 크게 변하지 않았습니다.

제품에 대한 사람들의 인식을 바꾸려면 세대가 필요하기 때문에

Java의 속도와는 아무런 관련이 없습니다. 사람들의 마음에 Java는 단어 'slow'와 관련된 const 식별자입니다. 당신이나 오라클이 할 수있는 일은 거의 없습니다.

Oracle이 rash 또는 stupid를 수행하여 Java 프로그래밍 문화 (아직)를 파괴하지 않았 음을 기뻐하십시오 . 라이센스 비용을 과도하게 청구하는 것과 같습니다. 또는 Sun이 이전에 소유 한 소프트웨어 특허를 기반으로 사람들을 고소합니다. ::한숨::

나는 여기에 naysayer가 싫지만 Oracle과 Google이 좋은 용어로 Java 투쟁을 해결하거나 Google이 Java를 구매하여 '적절한'오픈 소스 플랫폼으로 만들지 않는 한 Java는 아이가되는 길입니다. 이가있는 놀이터. IE, 아무도 20ft 극으로 만지고 싶지 않습니다.

참고 : 명확하게 말하면, 세대를 말할 때 컴퓨터 용어가 아닌 사람들 용어로 이야기하고 있습니다. IE, 그 지각을 가진 사람들이 나이가 들면서 죽거나 젊은 세대로 대체 될 때까지 지각은 사실이 될 것이다. 5 년이 아닌 50 년으로 생각하십시오.

한 가지 이유는 사람들이 다른 사람의 말을 신뢰하지 않고 신뢰하기 때문입니다 .

프로그래밍을 처음 시작할 때 들었던 바에 따르면, Java는 C ++보다 "느리게", Java를 사용할 수있는 이유는 "편리하고 쉬우 기"때문입니다. Java는 성능을 희생시키면서 안전과 편의성을 제공한다고 일반적으로 믿어집니다. 나중에 C #이 발명 되더라도 사람들은 "네이티브"이기 때문에 자바보다 빠르다고 생각합니다.

그러나 사람들이 그것을 알지 못하고 본 사실은, 일식, Java로 빌드 된 IDE는 절대적으로 가장 빠른 IDE라는 것입니다. 저는 거의 모든 주요 스트림 IDE를 사용했습니다. MS와 GNU, Borland 등의 Eclipse는 Eclipse의 절대 왕이며 IDE 덕분에 빠릅니다.

또 다른 이유는 시작 시간 이 길기 때문입니다 .

Java는 시스템 트레이에 머무르고 작은 메모리를 사용하며 휴식을 취하라는 대화 상자를 팝업하는 작은 앱을 개발하는 데 적합하지 않습니다. 또는 텍스트 파일을 열고, 읽고 닫는 데 사용하는 메모장. 항상 존재하는 웹 서버와 같이 컴퓨팅 리소스를 최적화하고 매시간 수백만 건의 요청에 응답하는 BIG에 사용해야합니다. 또는 수천 개의 작업 공간 파일을 관리하는 이클립스와 같은 IDE. 적어도 몇 시간 동안 실행될 때까지 Java 앱이 빠르다는 것을 알지 못합니다.

@bigown "왜 사람들은 여전히 ​​Java가 느리다고 말합니까?"

그들은 바보이기 때문에. 그들이 일 경험이 없기 때문에 그들이 Dikjstra의 살아있는 화신 또는 Linus Torvald의 재림이라고 생각합니다. 그런 지체 된 말을하는 이유는 너무나 많지만 대개 어리 석음, 무관심한 주관적인 팬보이 즘, 정서적 관심을 가진 사람들이 그들 뒤에있는 것 같습니다.

위에서 방금 말한 내용의 진실을 볼 수 있도록 이것을 배제하자 :

첫째, 어떤 상황에서 어떤 공학적 / 과학적 / 사업 적 목적으로 무엇을 느리게, 어떤 맥락에서, 느리게 하는가? 는 짜증 tehe이 그들 중 하나가 아닙니다.)라고 어떤 사람이 어떤 기술에 대해 "X가 느리다" X, 또는 단순히 "X는 Y"입니다. 여기서 Y는 부정적 진술의 한 유형이며, 위의 질문에 대답하지 않고 바보로 기각해야합니다. 이와 같은 진술은 엔지니어링 분야가 아닙니다. 정치 및 청소년 대화방에서는 엔지니어링이 아닐 수도 있습니다.

둘째, ZOMG 때문에 잘못 알려진 바보들 대부분은 자바가 느리다는 것에 대해 울부 짖습니다. 그들의 식은 영원히 불을 지피고 있습니다. 이클립스가 빠르게 작동하도록 (또는 그 문제에 대한 Java 응용 프로그램을 위해) jvm을 조정하십시오. 즉, 성능 조정에 대한 단서가 없습니다. 이는 Java뿐만 아니라 하드웨어 나 소프트웨어가 아닌 사소한 시스템에 대한 현실입니다. 그래서 바로 그러한 정신없는 진술을하는 데있어 기술적 타당성을 스스로 해제합니다.

셋째, 대량의 Java 개발이 무엇인지 고려해 보자. 우선 백엔드 OLTP; 모니터링 시스템이 두 번째로 나옵니다. 두 가지 유형의 시스템은 클러스터에서 실행되며 몇 개월이 아니라도 몇 주 동안 중단없이 실행됩니다. REAL Java 앱의 목적이 장기간 실행되는 경우 작은 일식 또는 장난감 앱을로드하는 데 1 ~ 2 분이 걸리는 것이 정말로 중요합니까? 상황, 사람, 상황.

마지막으로 Google과 Ebay에서 OLTP의 중추는 Java에서 실행됩니다. 필자는 자바가 느리지 않다는 증거로 (최소한 장난감 실험, 벤치 마크 및 검증 할 수없는 일화 적 증거가 아니라 "테헤 X가 느리다.

공학이 있고 팬보이가 있습니다. 그와 같은 카테고리 진술이 무엇인지 추측하십니까?

왜냐하면이 주제를 영원히 영원히 닫을 수 있습니까?

https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf [테이블로 스크롤하면 Java가 C ++보다 3.7-12.6 배 느리며 Google 직원의 조사]

추신 : 그렇지 않다면 시작하기 전에 하나 이상의 멋진 Java 응용 프로그램을 지정하십시오.

TMHO, 이것은 브라우저에서 VM을 시작하는 데 필요한 시간 때문입니다. 응용 프로그램이 느리게 시작되면 사람들은 그 사실 만 기억할 것입니다. 긴 시작 시간은 정말 성가시다. 정말. 동료 중 한 명이 Firefox가 너무 느리기 때문에 Firefox를 사용하지 않는다고 말했습니다. (?!?). 그러나 그렇습니다. Windows에서는 Firefox가 표시되는 데 많은 시간이 걸립니다. 그에 따르면,이 응용 프로그램은 느리다, 그는 그것의 일반적인 속도에 대해 생각했다.

무엇에 비해 느리게? 나는 그것이 더 빠르다는 것을 들었 기 때문에 일반 루비에서 JRuby (Java 기반 루비)로 변경하려고 생각하고 있습니다.

의견은 의견이며 사실은 사실입니다.

다음은 프로그래머가 어려운 컴퓨팅 문제를 단기간에 해결하도록 도전하는 Google Code Jam의 사실입니다. 즉, 사용하는 언어의 성능이 중요한 역할을합니다.

지난 버전 (2009, 2010, 2011) 동안에는 최종 라운드에 도착한 프로그래머의 약 75 %가 C ++을 사용했지만 Java를 사용하는 경우 약 15 %였습니다.

출처-> http://www.go-hero.net/jam/

1997 년경 HP Vectra VE (200MHz)와 Windows 95를 사용했습니다. 대부분의 응용 프로그램은이 작업에서 매우 빠르게 실행되었지만 Java로 작성된 몇 가지 응용 프로그램 (정확히 기억하면 IDE)을 사용해 보았습니다. 적어도 GUI 부분은 매우 느 렸습니다. 시작하는 데 시간이 오래 걸리고 GUI 요소 (예 : 메뉴)가 반응이 좋지 않아 시각적 피드백이 지연되었습니다. 또한 Java GUI 응용 프로그램은 다소 독특한 모양을 가지고 있기 때문에이 모양 (및 Java)을 열악한 성능과 연결하는 방법을 배웠습니다.

그것은 당신이 느리다는 것을 의미합니다.

우선, java는 최근 많은 발전을 이룩했으며 대부분의 경우 매우 빠릅니다. 그러나 :

• 어떤 작업을 수행하기 전에 JVM을로드해야하기 때문에 시작시 Java가 느려집니다.
• 일부 보안 기능은 경우에 따라 성능을 저하시킬 수 있습니다. 랜덤 액세스를 통한 바운드 검사는 예입니다.
• 자바에서 실제로 빠른 것을 만들어야합니다 (예 : 캐시 라인을 활용하기 위해).
• 메타 프로그래밍이 없다는 것은 각 추상화에서 런타임시 불이익을 의미하므로 성능은 많은 경우 설계 비용이 발생합니다.
• Java는 의도적으로 실시간 제약 조건을 보장 할 수 없으며 일부 사람들은이를 "느린"것으로 간주 할 수 있습니다.

그건 그렇고, 자바는 바닐라 C / C ++보다 빠릅니다. 그러나 그 언어는 그것들을 조정할 수있는 도구를 제공합니다.

Java는 생산성을 목표로하는 프로그래밍 언어입니다. 이제는 대부분의 응용 프로그램에는 충분히 빠르지 만 다른 응용 프로그램에는 충분하지 않습니다.

일반적으로 Java의 속도 저하는 대부분의 경우 관련이 없기 때문에 과도하게 사용되는 주장입니다.

간단한 표준 Java 코드는 간단한 표준 C / C ++ / D 코드와 동등하거나 더 빠른 경향이 있습니다. 단순하고 표준적인 코드는 불필요하게 많은 메모리 할당을 수행하는 경향이 있으며, 특히 CPU 아키텍처에 맞게 조정되지 않으며, 저수준 최적화가 수행되지 않는 등의 작업이 필요합니다. Java의 HotSpot GC는 놀랍지 않으며 VM 최적화는 경향이 있습니다. 정적 컴파일러가 할 수있는 것보다 낫습니다.

반면, 실제로 성능 이 필요하고이를 조정하기 위해 기꺼이 조정하려는 경우 C / C ++ / D는이를위한 더 많은 기회를 제공합니다. Java에서는 인라인 어셈블러를 사용할 수 없습니다. 부동 소수점 숫자를 비트 배열로 취급하기 위해 더티 타입의 장난 꾸러기를 사용할 수 없습니다. 특정 사용 사례에 대해 GC보다 빠른 사용자 지정 메모리 관리 체계를 사용할 수 없습니다. C / C ++ / D에서와 같이 Java에서 거의 스택에 할당 할 수 없습니다. Java에서 고차 함수와 거의 동등한 것을 얻는 유일한 방법은 인터페이스와 런타임 바인딩을 사용하는 것입니다. D와 (내 생각에 틀렸다면 수정하십시오) C ++에서 함수를 템플릿에 전달하여 유연성을 잃지 않고 컴파일 타임에 바인딩을 수행 할 수 있습니다.

Java의 "느린 속도"에 대한 또 다른 요점은 64 비트 런타임입니다.

일부 사람들은 Java가 64 비트 컴퓨터에서 매우 느리다고 불평합니다. 64 비트 Java 런타임은 시작하기 전에 전체 프로그램을 컴파일하는 서버 JVM을 사용합니다.

여기 64 비트 VM이 느리게 시작되는 이유에 대한 설명입니다.

예를 들어 Windows의 경우 :

C:\> java -version  
java version "1.6.0_21"  
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)  
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)  

그러나 Java의 성능은 매우 주관적이지만 Java가 느린 이유에 대한 인식은 주로 다른 사람들이 지적한 이유 때문입니다. 대부분의 사람들은 무언가에 대한 초기 경험에 의해 색이 지정되어 있으며 Java는 항상 잘 최적화 된 언어는 아닙니다. 후드. 마찬가지로 바닐라 이클립스는 Visual Studio와 같은 IDE와 비교할 때 반응 속도 측면에서 작동하고 창백하기에 빠른 IDE가 아닙니다.

그러나 Java가 시작될 때 UI 문제 외부에서는 대부분의 응용 프로그램에 충분히 빠릅니다. 검색하면 다른 언어 와 비교할 수있는 기사를 찾을 수 있으며 제시된 대부분의 결과는 주요 데이터 세트를 처리 할 때 문제가되는 범위에 속합니다.

생물 정보학 분야에서는 잘 지원되고 이미 설치 기반이 있기 때문에 꽤 많이 사용됩니다 .Java의 장점 중 하나는 C로 할 수없는 상당히 빠른 개발을 할 수 있다는 것입니다 생물 정보학에 사용되는 언어 (개인적으로 R, Python 및 Java를 정기적으로 사용)를 살펴보면, 그중에서 가장 빠른 언어는 없으며 생물 정보학의 데이터 세트가 100 년대에 빠지는 것은 드문 일이 아닙니다. 기가 바이트의 정보. 하루가 끝나도 인간의 시간은 여전히 ​​더 가치가 있으며 속도 차이는 눈에 띄지 만 데이터 세트의 크기는 어쨌든 밤새도록 충분히 큰 경향이 있습니다.

Java로 빠른 UI를 작성하는 것이 더 쉽다면 대부분의 사람들이 언어를 충분히 강요하지 않기 때문에 속도 인식이 레이더에서 떨어질 것입니다. 매일 속도가 실제로 문제입니다.

쓸모없는 동전을 던지기 위해 Java webapps는 일반적으로 시작 및 응답 시간이 길다는 것을 알았습니다. 파이썬 또는 루비가 더 잘했을 것입니다.

필자는 대부분의 프로그래밍에 Eclipse를 사용하고 있으며 로컬에서 "독립형"으로 빠르게 실행되지 않으면 Java가 다른 것만 큼 빠르다고 말해야한다.

Java는 실제 고수준 언어에서 쉬운 간단한 문제를 해결하지 못하기 때문에 느린 것이 아니라 느리게 말합니다.

간단한 예를 들어 보겠습니다. 삼림 벌채라고하는 목록을 두 번 매핑 할 때 적용되는 간단한 최적화가 있습니다. 여기 내 언어 Felix로 작성된 규칙이 있습니다.

reduce deforest[T,U,V] (f:T->U, g:U->V, x:list[T]): 
  map g (map f x) => map (compose(g,f)) x
;

즉, 목록 x를 f로 매핑하는 대신 g로 다시 매핑하여 두 개의 목록 탐색이 필요하고 가비지 임시 목록을 만들려면 함수 구성으로 목록을 매핑하면됩니다.

이것은 Java JVM의 저수준 성능보다 훨씬 중요한 고수준 최적화 입니다. 위에서 지정한 사양은 단순한 구문이 아니라 사용자가 Felix 컴파일러에게 최적화를 수행하는 방법을 알려주 는 명령 입니다.

Java에서 이런 종류의 작업을 수행하는 방법을 알려주십시오. 아니? 그러면 Java가 느립니다. 아주 느린. [Haskell은이 작업을 자동으로 수행 할 수 있습니다].

그리고 당신이 말하기 전에 "하지만 Java는 OO 언어입니다. 이런 종류의 최적화는 적용되지 않습니다." Java가 짜증나고 OO가되는 것이 주된 이유 중 하나입니다.

JIT 최적화는 괜찮은 컴파일러가 할 수있는 종류의 최적화와 경쟁 ​​할 수 없습니다.