it-swarm-vi.com

Tại sao mọi người vẫn nói Java là chậm?

Trong một thời gian dài ở SO và ở những nơi khác Java có tiếng là chậm. Từ truyện cười đến nhiều bình luận trong câu hỏi và câu trả lời, mọi người vẫn tin Java chậm chỉ dựa vào kinh nghiệm với nó trong những năm 90.

Đây là vấn đề của tôi: chúng tôi có không được chấp thuận (hầu hết) các lý do mà mọi người tin rằng Java là chậm. Ngoài những thứ nhỏ nhặt, Java khá nhanh.

Vậy tại sao mọi người vẫn từ chối tin Java bây giờ thì nhanh? Có phải đó là một phần trong suy nghĩ của họ rằng bất cứ điều gì không phải C/C++ đều chậm? Có phải vì mọi người không kiểm tra theo thời gian? Có phải vì con người chỉ thiên vị?

61
TheLQ

Đó là các ứng dụng. Như bạn lưu ý, chúng tôi đã đã chứng minh, hết lần này đến lần khác, rằng trong các kịch bản có sẵn Java có thể đáp ứng hoặc thậm chí beat hiệu suất của cái gọi là các ngôn ngữ "biểu diễn" như C, C++, LISP, VB6 hoặc JavaScript.

... nhưng sau đó, họ kích hoạt Eclipse, hoặc NetBeans hoặc Guiffy hoặc bật hỗ trợ Java trong trình duyệt của họ hoặc thử chạy một ứng dụng trên điện thoại tính năng yêu thích của họ. Và họ chờ để nó trở nên nhạy bén ...

...và chờ đợi...

...và chờ đợi...



...và chờ đợi...







...và chờ đợi...











[.__.] ... và ...




[.__.] ... Tôi đã hứa sẽ không bao giờ làm gì nữa? Xin lỗi, phải ngủ gật ...

131
Shog9

Câu hỏi này hoạt động trên các tiền đề sai: nơi nó đếm, Java vẫn chậm. Trường hợp nó là thuật toán nặng tính toán trên các tập dữ liệu lớn. Được cấp, những cái này có thể được tối ưu hóa, đôi khi để ngang bằng với mã C/C++, nhưng chỉ với chi phí mô đun hóa và tính tổng quát. Mã C++ hiệu quả có thể được thiết kế để chung chung và có thể sử dụng như một thư viện cho mục đích chung. Java không thể. Chỉ cần nhìn vào phương thức Array.sort Được tối ưu hóa mạnh mẽ, sử dụng các triển khai khác nhau cho tất cả các loại cơ bản và biến thể đối tượng vẫn là much chậm hơn so với C++ 'generic sort vì các đối tượng này phải gửi các phép so sánh bằng nhau một cách linh hoạt.

Cấp, tối ưu hóa kịp thời như được thực hiện bởi công cụ HotSpot thực sự có thể dự đoán mục tiêu của các cuộc gọi ảo này và cố gắng nội tuyến. Nhưng đây là vẫn chậm so với lệnh gọi trực tiếp được gửi bên trong phương thức C++, sort.

Một đồng nghiệp cũ của tôi đã thực hiện các tiêu chuẩn so sánh của một vấn đề trên các tập dữ liệu khổng lồ ( q - đếm gram bằng cách sử dụng hình dạng động) với triển khai C++ được tạo khuôn mẫu và một hướng đối tượng Java. Mã Java là các lệnh có độ lớn chậm hơn mã C++.

Tất nhiên đây là so sánh táo với cam. Nhưng vấn đề là việc thực hiện Java là cách triển khai tốt nhất có thể (về hiệu suất, với mức độ mô đun hóa cần thiết cho một thư viện), và việc triển khai C++ cũng vậy.

Thật không may, dữ liệu điểm chuẩn không có sẵn miễn phí nhưng những người khác đã tìm thấy những con số tương tự khi so sánh chi phí trừu tượng thời gian chạy. Chẳng hạn, Scott Meyers viết trong STL hiệu quả về chi phí hoạt động của hàm C chung qsort:

C++ sắp xếp hầu như luôn làm xấu hổ Ciên qsort khi nói về tốc độ. [Vùi] Trong thời gian chạy, sort thực hiện các cuộc gọi nội tuyến đến chức năng so sánh của nó trong khi qsort gọi chức năng so sánh của nó thông qua một con trỏ. [Lôi] Trong các thử nghiệm của tôi trên một vectơ triệu triệu, [sort] đã chạy nhanh hơn tới 670%

48
Konrad Rudolph

Bởi vì nó chậm ... trong một số ứng dụng. Các ứng dụng máy tính để bàn phải được đáp ứng ngay từ đầu và chi phí khởi động được tính là chậm.

Mặt khác, nếu bạn chạy một máy chủ thì không vấn đề gì nếu có một số hệ thống sưởi (phân tích và biên dịch JIT) - bạn thực hiện một lần trong trăng xanh nên hầu hết thời gian nó không thể được coi là hoàn toàn chậm.

28
Maciej Piechotka

Tôi muốn nói rằng bởi vì khi mọi người lần đầu tiên gặp nó, nó đã chậm. Dựa vào đó, họ đã hình thành một ấn tượng về nó. Ấn tượng đó khó có thể thay đổi nếu họ không sử dụng nó và họ không sử dụng nó vì ấn tượng đó - đó là một vòng luẩn quẩn.

Tôi phải thừa nhận, tôi đã có ấn tượng rằng Java là chậm, và vâng, đó là từ lần tiếp xúc trước với tôi. Bây giờ tôi đã chuyển sang các ngôn ngữ khác nhau và đã tiếp xúc rất hạn chế với Java kể từ đó. Do đó, ý kiến ​​của tôi đã không thay đổi nhiều.

21
Damovisa

Bởi vì phải mất một thế hệ để thay đổi nhận thức của mọi người về một sản phẩm

Nó không liên quan gì đến việc nhanh như thế nào Java. Trong suy nghĩ của mọi người Java là một định danh const liên quan đến từ 'chậm'. Có rất ít, không có gì bạn hoặc Oracle có thể làm về nó.

Hãy vui mừng vì Oracle đã không phá hủy Java văn hóa lập trình (chưa) bằng cách làm bất cứ điều gì phát ban hoặc ngu ngốc . Giống như tính chi phí cấp phép quá mức để sử dụng nó. Hoặc kiện mọi người dựa trên các bằng sáng chế phần mềm trước đây thuộc sở hữu của Sun. :: thở dài ::

Tôi ghét phải là người theo dõi ở đây nhưng, trừ khi Oracle và Google giải quyết Java đấu tranh theo các điều khoản Nice hoặc Google buộc phải mua Java và biến nó thành Nền tảng nguồn mở 'phù hợp', Java cũng là cách để trở thành đứa trẻ trên sân chơi có chí. IE, không ai muốn chạm vào nó với cột 20ft.

Lưu ý: Để rõ ràng, khi tôi nói thế hệ tôi đang nói về những người không phải là thuật ngữ máy tính. IE, cho đến khi những người nắm giữ nhận thức đó chết vì già hoặc được thay thế bởi một thế hệ trẻ, nhận thức sẽ đúng. Nghĩ về 5 thập kỷ chứ không phải 5 năm.

16
Evan Plaice

Một lý do là mọi người tin tưởng những gì người khác nói thay vì những gì họ thấy.

Theo những gì tôi đã nói khi lần đầu tiên bắt đầu lập trình, Java "chậm" hơn C++ và lý do tại sao Java có thể được sử dụng là vì nó "tiện lợi và dễ dàng hơn ". Người ta thường tin rằng Java mang lại sự An toàn và tiện lợi, với chi phí hiệu năng. Ngay cả khi sau này C # được phát minh, mọi người tin rằng nó nhanh hơn Java bởi vì nó là "bản địa".

Nhưng sự thật mọi người nhìn thấy mà không cảm nhận được, đó là, Eclipse, IDE được xây dựng bằng Java, hoàn toàn là FASTEST IDE trong lớp. Tôi đã đã sử dụng gần như tất cả các IDE luồng chính, những người từ MS và GNU, Borland ..., Eclipse là vua tuyệt đối, của IDE, phần lớn là do nó nhanh.

Một lý do khác là thời gian khởi động dài.

Java không phù hợp để phát triển một ứng dụng nhỏ nằm trong khay hệ thống, tiêu tốn một ít bộ nhớ, bật lên hộp thoại nhắc nhở bạn nghỉ ngơi; hoặc một notepad mà bạn sử dụng để mở tệp văn bản, đọc nó và đóng nó. Nó nên được sử dụng trên một cái gì đó LỚN, như một máy chủ web luôn ở đó, sử dụng tối ưu hóa tài nguyên máy tính của bạn, đáp ứng hàng triệu yêu cầu mỗi giờ. Hoặc một IDE như Eclipse quản lý hàng ngàn tệp không gian làm việc. Bạn không biết bạn Java nhanh cho đến khi nó chạy ít nhất vài giờ, Tôi tin.

11
tactoth

@bigown "Tại sao mọi người vẫn nói Java là chậm?"

Vì họ câm. Bởi vì họ không có kinh nghiệm làm việc, nhưng nghĩ rằng họ là hóa thân sống của Dikjstra hoặc lần thứ hai của Linus Torvald, oh tôi dunno. Những lý do để nói một điều chậm phát triển như vậy là rất nhiều, nhưng thường là sự ngu ngốc, sự cuồng tín chủ quan không suy nghĩ và sự chú ý tình cảm dường như đằng sau chúng.

Hãy xem xét điều này để bạn có thể thấy sự thật của những gì tôi vừa nói ở trên:

Đầu tiên, cái gì chậm, trong bối cảnh nào, vì cái gì, trong điều kiện nào, với mục đích kỹ thuật/khoa học/kinh doanh nào (để nói tehe nó hút không phải là một trong số họ.) X chậm "đối với bất kỳ công nghệ X nào, hoặc đơn giản là" X là Y "trong đó Y là một loại tuyên bố tiêu cực, mà không trả lời bất kỳ câu hỏi nào ở trên nên bị loại bỏ như một kẻ ngốc. Những tuyên bố như thế không có chỗ trong kỹ thuật. Trong chính trị và phòng trò chuyện vị thành niên có thể, nhưng không phải về kỹ thuật.

Thứ hai, hầu hết những kẻ ngốc sai lầm này đều khóc về Java bị chậm vì ZOMG, Eclipse của họ mất thời gian để khởi động (gee, tải mọi thứ với tất cả các trình cắm và đoán xem điều gì sẽ xảy ra.) trong số những kẻ ngu ngốc này thậm chí không biết cách điều chỉnh jvm để Eclipse hoạt động nhanh (hoặc cho bất kỳ Java cho vấn đề đó). Đó là, họ không biết gì về điều chỉnh hiệu năng, mà là một thực tế không chỉ đối với Java, mà đối với bất kỳ hệ thống không tầm thường nào, có thể là phần cứng hoặc phần mềm. Vì vậy, ngay tại đó, họ vô hiệu hóa bất kỳ giá trị kỹ thuật nào khi đưa ra những tuyên bố thiếu suy nghĩ như vậy.

Thứ ba, hãy xem xét phần lớn của Java là gì: back end OLTP trước hết và quan trọng nhất là các hệ thống giám sát sắp tới. chạy theo cụm và để chạy liên tục trong nhiều tuần nếu không phải hàng tháng. Điều đó có thực sự quan trọng không khi ứng dụng Eclipse hoặc đồ chơi nhỏ của bạn mất một hoặc hai phút để tải khi mục đích của REAL Java để chạy trong thời gian dài? Bối cảnh, con người, bối cảnh.

Cuối cùng, xương sống của OLTP trên Google và Ebay chạy trên Java. Tôi sẽ lấy đó làm bằng chứng bằng mâu thuẫn rằng Java không chậm (ít nhất là đối với điều kiện quan trọng, không phải cho các thí nghiệm đồ chơi nhỏ, điểm chuẩn và bằng chứng phụ lục không thể kiểm chứng được thực hiện cụ thể cho mục đích nói "tehe X chậm, nó tệ."

Có kỹ thuật, và có fanboyism. Đoán xem những tuyên bố thể loại như thế nào thuộc về?

8
luis.espinal

Bởi vì nó là, chúng ta có thể đóng chủ đề này một lần và mãi mãi?

https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf [cuộn xuống các bảng, Java là 3,7 -12,6 lần chậm hơn C++, nghiên cứu của nhân viên Google]

P.S.: Nếu không, hãy đặt tên cho tôi ít nhất một snappy Java ứng dụng để bắt đầu, chưa từng thấy cái nào trước đây.

8
Coder

Chậm so với cái gì? Tôi đang nghĩ đến việc thay đổi từ bình thường Ruby thành JRuby (Ruby dựa trên Java) vì tôi đã nghe thấy nó nhanh hơn.

6
Andrew Grimm

Ý kiến ​​là ý kiến, và sự thật là sự thật.

Đây là một thực tế từ Google Code Jam, được cho là thách thức các lập trình viên để giải quyết các vấn đề máy tính khó khăn trong một khoảng thời gian ngắn, có nghĩa là hiệu suất của ngôn ngữ họ sử dụng đóng một vai trò quan trọng:

Trong các phiên bản vừa qua (2009, 2010, 2011), khoảng 75% lập trình viên đến vòng cuối cùng đang sử dụng C++, trái ngược với khoảng 15% sử dụng Java.

Nguồn -> http://www.go-hero.net/jam/

6
Daniel Scocco

TMHO, điều này là do thời gian cần thiết để bắt đầu VM trong trình duyệt. Nếu một ứng dụng khởi động chậm, mọi người sẽ chỉ nhớ điều đó. Bởi vì, thời gian bắt đầu dài thực sự rất khó chịu. đồng nghiệp của tôi nói với tôi rằng anh ta không sử dụng Firefox vì nó quá chậm. (?!?). Nhưng, vâng, trên các cửa sổ, Firefox mất một lượng lớn thời gian để hiển thị. Theo anh ta, Ứng dụng này rất chậm, anh ấy đã suy nghĩ về tốc độ chung của nó.

6
Pierre Watelet

Circa 1997 Tôi đã sử dụng HP Vectra VE (200 MHz) và Windows 95. Hầu hết các ứng dụng chạy rất nhanh về điều này, nhưng sau đó tôi đã thử một vài ứng dụng được viết bằng Java (IDE, nếu tôi nhớ lại chính xác ). Chúng rất chậm, ít nhất là các phần GUI của chúng. Chúng mất nhiều thời gian để khởi động và các thành phần GUI (ví dụ: menu) không phản hồi nhanh - có sự chậm trễ trong phản hồi trực quan. Ngoài ra, vì Java Các ứng dụng GUI có (có) một giao diện khá đặc biệt, tôi đã học cách liên kết giao diện này (và Java) với hiệu suất kém.

4
Andreas Rejbrand

Nó phụ thuộc vào những gì bạn có nghĩa là chậm.

Trước hết, Java như đã đạt được nhiều tiến bộ gần đây và rất nhanh trong hầu hết các trường hợp. Nhưng:

  • Java khởi động chậm, vì bạn phải tải JVM trước khi làm bất cứ điều gì.
  • Một số tính năng bảo mật có thể giết chết màn trình diễn trong một số trường hợp. Kiểm tra ràng buộc với truy cập ngẫu nhiên là một ví dụ.
  • Tạo một cái gì đó thực sự nhanh trong Java yêu cầu phải hoạt động chống lại JVM (để tận dụng lợi thế của dòng bộ đệm cho ví dụ).
  • Việc thiếu lập trình siêu dữ liệu ngụ ý tính hợp pháp trong thời gian chạy với mỗi lần trừu tượng hóa, do đó hiệu suất đi kèm với chi phí thiết kế trong nhiều trường hợp.
  • Java khó có thể đảm bảo ràng buộc thời gian thực - theo thiết kế - và điều này có thể được coi là "chậm" bởi một số người.

Nhân tiện, Java, trong một số trường hợp, nhanh hơn Vanilla C/C++. Nhưng các ngôn ngữ này cung cấp cho bạn các công cụ để Tweak chúng.

Java là một ngôn ngữ lập trình nhằm mục đích năng suất. Bây giờ nó đủ nhanh cho hầu hết các ứng dụng, nhưng không đủ cho một số ứng dụng khác.

Nói chung, sự chậm chạp của Java là một đối số được sử dụng quá mức bởi vì nó không phù hợp trong hầu hết các trường hợp.

4
deadalnix

Đơn giản, canonical Java có xu hướng ngang bằng hoặc nhanh hơn mã C/C++/D đơn giản, đơn giản. Mã đơn giản, có xu hướng thực hiện nhiều phân bổ bộ nhớ một cách không cần thiết, không đặc biệt được điều chỉnh theo bất kỳ kiến ​​trúc CPU nào, không có hàng tấn tối ưu hóa mức thấp nào được thực hiện cho nó, v.v. HotSpot GC của Java không có gì đáng ngạc nhiên, và tối ưu hóa VM có xu hướng tốt hơn so với trình biên dịch tĩnh Có thể làm.

Mặt khác, nếu bạn thực sự cần hiệu suất và sẵn sàng điều chỉnh công cụ để có được nó, C/C++/D cung cấp nhiều cơ hội hơn cho việc này. Bạn không thể sử dụng trình biên dịch nội tuyến trong Java. Bạn không thể sử dụng các thủ thuật xảo quyệt bẩn để coi các số dấu phẩy động là các mảng bit. Bạn không thể sử dụng các lược đồ quản lý bộ nhớ tùy chỉnh có thể nhanh hơn GC cho trường hợp sử dụng cụ thể của bạn. Bạn không thể phân bổ gần như nhiều trên ngăn xếp trong Java như trong C/C++/D. In Java cách duy nhất để có được bất cứ thứ gì tương đương với Các hàm bậc cao hơn là với các giao diện và ràng buộc thời gian chạy. Trong D và (tôi nghĩ, hãy sửa tôi nếu tôi sai) C++, bạn có thể chuyển các hàm cho các mẫu, cho phép liên kết xảy ra trong thời gian biên dịch mà không mất tính linh hoạt.

2
dsimcha

Một điểm khác cho "sự chậm chạp" của Java là thời gian chạy 64 bit.

Tôi đã nghe một số người phàn nàn rằng Java rất chậm đối với họ trên máy tính 64 bit. Khi nó bật ra, 64bit Java runtime sử dụng máy chủ JVM để biên dịch toàn bộ chương trình trước khi bắt đầu.

TẠI ĐÂY là lời giải thích tại sao 64bit VM bắt đầu chậm hơn.

Ví dụ trên 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)  
1
AndrejaKo

Để ném vào một đồng xu vô giá trị, tôi thấy rằng Java webapps thường có thời gian khởi động và phản hồi lâu, trong đó dường như với tôi rằng Python hoặc Ruby sẽ làm tốt hơn.

Tôi sử dụng Eclipse cho hầu hết các chương trình của mình và tôi phải nói rằng Java cũng nhanh như mọi thứ khác, nếu không chạy nhanh hơn cục bộ và "độc lập".

0
thomas

Hiệu suất của Java rất chủ quan, tuy nhiên, nhận thức về lý do tại sao Java chậm phần lớn là vì những lý do mà người khác đã lưu ý: hầu hết mọi người đều nhận thấy điều gì đó có màu bởi kinh nghiệm trước đây của họ với nó và Java không phải luôn là ngôn ngữ được tối ưu hóa tốt trong phần mềm. Tương tự, Vanilla Eclipse không chính xác là nhanh IDE để làm việc với và nhợt nhạt về khả năng đáp ứng khi so sánh với một IDE như Visual Studio.

Mặc dù vậy, bên ngoài các vấn đề về UI mà Java có khi khởi động, nó đủ nhanh cho hầu hết các ứng dụng. Nếu bạn tìm kiếm, bạn có thể tìm thấy các bài viết so sánh nó với các ứng dụng khác ngôn ngữ và hầu hết các kết quả được trình bày đưa nó vào phạm vi mà nó sẽ chỉ là vấn đề khi bạn đang xử lý các tập dữ liệu chính.

Trong lĩnh vực tin sinh học, nó được sử dụng khá nhiều vì nó được hỗ trợ tốt và đã có cơ sở cài đặt, một trong những lợi thế mà Java là bạn có thể phát triển khá nhanh với đó là điều bạn không thể làm với C. Nếu bạn xem các ngôn ngữ được sử dụng cho tin sinh học (cá nhân tôi sử dụng R, Python và Java thường xuyên), bạn sẽ lưu ý rằng không có ngôn ngữ nào chính xác là nhanh nhất và không có gì lạ khi các bộ dữ liệu trong tin sinh học chạy vào 100 gigabyte thông tin. Vào cuối ngày, thời gian của con người vẫn có giá trị hơn và trong khi sự khác biệt về tốc độ là đáng chú ý, kích thước của các bộ dữ liệu có xu hướng đủ lớn để họ chạy qua đêm.

Nếu việc viết một giao diện người dùng linh hoạt dễ dàng hơn trong Java thì khá giống như nhận thức về tốc độ sẽ rơi ra khỏi radar vì hầu hết mọi người không đẩy ngôn ngữ đủ để tốc độ thực sự là vấn đề hàng ngày nền tảng.

0
rjzii