Tại sao mọi người vẫn nói Java chậm? [đóng cửa]

Trong một thời gian dài ở SO và ở những nơi khác, Java có tiếng là chậm. Từ những câu chuyện cười cho đến nhiều bình luận trong các câu hỏi và câu trả lời, mọi người vẫn tin rằng 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 đã bác bỏ (hầu hết) các lý do mà mọi người tin rằng Java chậm. Bên ngoài những điều nhỏ nhặt, Java khá nhanh.

Vậy tại sao mọi người vẫn từ chối tin rằng Java nhanh như vậy? 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 là 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ì mọi người chỉ thiên vị?

Đó 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, trong các kịch bản bị chiếm dụng, mã Java có thể đáp ứng hoặc thậm chí đánh bại hiệu năng của các ngôn ngữ được gọi là "biểu diễn" như C, C ++, Lisp, VB6 hoặc JavaScript. Và khi được đưa ra bằng chứng như vậy, hầu hết các đối thủ lành mạnh, cởi mở sẽ treo đầu mình trong sự xấu hổ và hứa sẽ không bao giờ truyền bá lời vu khống đó nữa.

... nhưng sau đó, họ kích hoạt Eclipse, hoặc NetBeans hoặc Guiffy hoặc kích hoạ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ờ đợi nó trở nên phản hồi ...

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

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



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







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











... và ...




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

Câu hỏi này hoạt động trên cơ sở sai: nơi nó đếm, Java vẫn chậm. Trong đó nó là các thuật toán nặng tính toán trên các tập dữ liệu lớn. Cấp, những thứ 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 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 có mục đích chung. Mã Java không thể. Chỉ cần nhìn vào các yếu tối ưu hóa Array.sortphương pháp, trong đó sử dụng triển khai khác nhau cho tất cả các loại cơ bản, và có biến đối tượng vẫn còn nhiều chậm hơn so với C ++' chung sortvì các đối tượng này phải cử so sánh bình đẳng tự động.

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 điều này vẫn chậm hơn so với cuộc gọi nội tuyến trực tiếp được gửi bên trong sortphương thức C ++ .

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ồ ( đếm q -gram bằng cách sử dụng các hình dạng động) với việc triển khai C ++ theo khuôn mẫu và triển khai Java hướng đối tượng. Mã Java là các đơn đặt hàng có cường độ 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 triển khai Java là triển khai tốt nhất có thể (về hiệu năng, 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í chung của qsortchức năng chung của C :

Kiểu sắp xếp của C ++ hầu như luôn làm xấu hổ qsort của C 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%

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 có 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.

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 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 với Java rất hạn chế kể từ đó. Do đó, ý kiến ​​của tôi đã không thay đổi nhiều.

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 Java trở nên nhanh như thế nào. 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 văn hóa lập trình Java (chưa) bằng cách làm bất cứ điều gì điên rồ hoặc ngu ngốc . Giống như tính phí chi phí cấp phép quá mức để sử dụng nó. Hoặc kiện người dân dựa trên bằng sáng chế phần mềm do Sun sở hữu trước đây. ::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 cuộc đấu tranh Java theo các điều khoản tốt đẹp, hoặc Google buộc phải mua Java và biến nó thành một nền tảng nguồn mở 'phù hợp', Java cũng đang trên đường trở thành đứa trẻ sân chơi có chí. IE, không ai muốn chạm vào nó với một 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ẻ thì nhận thức sẽ vẫn đúng. Nghĩ về 5 thập kỷ chứ không phải 5 năm.

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ọ nhìn thấy .

Theo những gì tôi đã nói khi tôi mới 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 An toàn và tiện lợi, với chi phí hiệu năng. Ngay cả khi C # sau này được phát minh, mọi người vẫn tin rằng nó nhanh hơn Java 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à, nhật thực, IDE được xây dựng bằng Java, hoàn toàn là IDE NHANH NHẤT trong lớp. Tôi đã sử dụng gần như tất cả các IDE luồng chính, từ các MS và GNU, Borland ..., nhật thực là vua tuyệt đối, của các IDE, phần lớn là do nó nhanh.

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

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ư nhật thực quản lý hàng ngàn tệp không gian làm việc. Bạn không biết ứng dụng Java của bạn nhanh cho đến khi nó chạy được ít nhất vài giờ, tôi tin thế.

@bigown "Tại sao mọi người vẫn nói Java 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 không biết. 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 họ.

Hãy bỏ qua đ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 gì (để nói rằng nó không phải là một trong số chúng.) Bất kỳ ai nói "X chậm" đối với bất kỳ công nghệ nào X, hoặc đơn giản là "X là Y" trong đó Y là một loại câu phủ định, 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ẻ ngu ngốc này đều khóc vì Java bị chậm vì ZOMG, nhật thực của họ sẽ nổ tung mãi mãi (gee, tải mọi thứ với tất cả các trình cắm và đoán xem điều gì xảy ra.) Hầu hết những kẻ ngốc này thậm chí không biết làm thế nào để điều chỉnh jvm cho nhật thực để hoạt động nhanh (hoặc cho bất kỳ ứng dụng Java nào cho vấn đề đó). Đó là, họ không có manh mối về điều chỉnh hiệu năng, đó 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ản thân về bất kỳ giá trị kỹ thuật nào trong việc đư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 sự phát triển của Java là gì: OLTP back end trước hết và quan trọng nhất; hệ thống giám sát sắp tới thứ hai. Một trong hai loại hệ thống được dự định để chạy theo cụm và để chạy không bị gián đoạn trong nhiều tuần nếu không phải là vài tháng. Điều đó có thực sự quan trọng không khi ứng dụng nhật thực 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 các ứng dụng Java THỰC SỰ là 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 các đ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 xác thực không thể kiểm chứng được thực hiện cho mục đích nói "tehe X chậm, nó tệ."

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

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

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

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

TMHO, điều này là do thời gian cần thiết để khởi động VM trong trình duyệt. Nếu một ứng dụng bắt đầu 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ự gây phiền nhiễu. Có thật không. Một đồng nghiệp của tôi nói với tôi rằng anh ta không sử dụng Firefox vì quá chậm. (?!?). Nhưng, vâng, Ok, trên windows, Firefox mất một lượng lớn thời gian để hiển thị. Theo anh, ứng dụng này rất chậm, anh đã suy nghĩ về tốc độ chung của nó.

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

Ý 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 trước (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/

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ớ chính xác). Chúng rất chậm, ít nhất là các phần GUI của chúng. Họ mất nhiều thời gian để bắt đầu và các thành phần GUI (ví dụ: menu) không phản hồi nhiều - có sự chậm trễ trong phản hồi trực quan. Ngoài ra, vì các ứng dụng GUI Java 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 năng kém.

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 hiệu suất 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ụ.
• Làm cho một cái gì đó thực sự nhanh chóng 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 ngôn ngữ thoses cung cấp cho bạn các công cụ để tinh chỉnh 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.

Mã Java đơn giản, chuẩn có xu hướng ngang bằng hoặc nhanh hơn mã C / C ++ / D đơn giản, chuẩn. Đơn giản, mã chính tắc 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 điều chỉnh đặc biệt cho 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 được thực hiện cho nó, v.v. HotSpot GC của Java không có gì đáng kinh ngạc để tốt hơn những gì một 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 số dấu phẩy động là 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. Trong 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 tại thời gian biên dịch mà không mất tính linh hoạt.

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. Hóa ra, thời gian chạy Java 64 bit sử dụng máy chủ JVM để biên dịch toàn bộ chương trình trước khi bắt đầu.

ĐÂY là giải thích tại sao VM 64bit 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)  

Hiệu năng 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à những người khác đã lưu ý: hầu hết mọi người nhận thức về một cái gì đó được tô màu bởi kinh nghiệm trước đây của họ với Java và Java luôn luôn là một ngôn ngữ được tối ưu hóa tốt mui xe. Tương tự, vanilla Eclipse không chính xác là một IDE nhanh để làm việc và làm mờ đi 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 gặp phải 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ôn ngữ khác 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 có là bạn có thể thực hiện một số phát triển khá nhanh với nó mà bạn không thể làm với C Nếu bạn nhìn vào các ngôn ngữ được sử dụng cho tin sinh học (cá nhân tôi thường xuyên sử dụng R, Python và Java), bạn sẽ lưu ý rằng không có ngôn ngữ nào là chính xác nhất và không có gì bất thường khi các bộ dữ liệu trong tin sinh học chạy vào 100 hàng 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 bằng Java dễ dàng hơn, 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ém vào một đồng tiền vô giá trị, tôi thấy rằng các ứng dụng web Java thường có thời gian khởi động và phản hồi lâu, trong đó đối với tôi, 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".

Tôi muốn nói rằng Java rất chậm, không chỉ chậm chạp, bởi vì nó không giải quyết được các vấn đề đơn giản, dễ dàng trong các ngôn ngữ cấp cao thực sự.

Hãy để tôi đưa ra một ví dụ đơn giản. Có một tối ưu hóa đơn giản áp dụng khi ánh xạ danh sách hai lần, được gọi là phá rừng: đây là quy tắc cho nó được viết bằng ngôn ngữ của tôi:

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

trong đó nói: thay vì ánh xạ danh sách x với f, sau đó ánh xạ lại với g, yêu cầu hai lần duyệt danh sách và tạo danh sách tạm thời rác, chỉ cần ánh xạ danh sách với thành phần của các hàm.

Đây là một tối ưu hóa mức cao có ý nghĩa lớn hơn nhiều so với hiệu năng của JVM Java ở mức thấp. Thông số kỹ thuật tôi đã đưa ra ở trên không chỉ là cú pháp đẹp, đây là một hướng dẫn được viết bởi người dùng nói với trình biên dịch Felix cách thực hiện tối ưu hóa.

Vui lòng chỉ cho tôi cách thực hiện loại điều này trong Java. Không? Sau đó, Java là chậm. Rất chậm. [Tôi tin rằng Haskell có thể làm điều này một cách tự động].

Và trước khi bạn nói "nhưng Java là ngôn ngữ OO, loại tối ưu hóa này không áp dụng" .. đó chính xác là quan điểm của tôi. Java rất tệ và là OO là một trong những lý do chính.

Tối ưu hóa JIT không bao giờ có thể tiến gần đến việc cạnh tranh với các loại tối ưu hóa mà một trình biên dịch đàng hoàng có thể làm.