Có vẻ như bạn đang hỏi hai câu hỏi khá khác nhau:
- Là Java thực sự chậm, và nếu vậy tại sao?
- Tại sao Java được coi là chậm, mặc dù nó nhanh hơn nhiều lựa chọn thay thế?
Câu hỏi đầu tiên trong số này ít nhiều là một câu hỏi "bao lâu là một sợi dây". Nó đi xuống định nghĩa của bạn về "chậm". So với một trình thông dịch thuần túy, Java cực kỳ nhanh. So với các ngôn ngữ khác (thông thường) được biên dịch theo một loại mã byte nào đó, sau đó được biên dịch động thành mã máy (ví dụ C # hoặc bất cứ thứ gì khác trên .NET) Java gần như ngang bằng. So với các ngôn ngữ thường được biên dịch thành mã máy thuần túy và có các nhóm người (thường là lớn) không làm việc gì ngoài việc cải thiện trình tối ưu hóa của họ (ví dụ: C, C ++, Fortran, Ada) Java khá tốt ở một số điều, nhưng nhìn chung ít nhất có xu hướng chậm hơn một chút.
Rất nhiều thứ liên quan chủ yếu đến việc triển khai - về cơ bản, có một thực tế là người dùng đang chờ trong khi trình biên dịch động / JIT chạy, vì vậy trừ khi bạn có một chương trình chạy khá lâu để bắt đầu, đó là khó để biện minh cho việc trình biên dịch dành nhiều thời gian cho việc tối ưu hóa khó khăn. Do đó, hầu hết các trình biên dịch Java (và C #, v.v.) không đặt nhiều nỗ lực vào việc tối ưu hóa thực sự khó khăn. Trong rất nhiều trường hợp, nó ít hơn về những gì tối ưu hóa được thực hiện, hơn là nơi chúng được áp dụng. Nhiều vấn đề tối ưu hóa đã hoàn tất NP, vì vậy thời gian chúng phát triển nhanh chóng với quy mô của vấn đề bị tấn công. Một cách để giữ thời gian trong lý do là chỉ áp dụng tối ưu hóa cho một cái gì đó giống như một chức năng duy nhất tại một thời điểm. Khi chỉ có nhà phát triển chờ trình biên dịch, bạn có thể đủ khả năng để mất nhiều thời gian hơn và áp dụng tối ưu hóa tương tự cho các phần lớn hơn của chương trình. Tương tự như vậy, mã cho một số tối ưu hóa là khá nhiều lông (và do đó có thể khá lớn). Một lần nữa, vì người dùng đang chờ trong khi tải mã (và thời gian khởi động JVM thường là một yếu tố quan trọng trong thời gian tổng thể), nên việc triển khai phải cân bằng thời gian được lưu ở một nơi so với bị mất ở nơi khác - và cho biết ít mã lợi ích từ việc tối ưu hóa lông, giữ cho JVM nhỏ thường có lợi hơn.
Một vấn đề thứ hai là với Java, bạn thường xuyên nhận được một loại giải pháp "một kích thước phù hợp với tất cả". Ví dụ, đối với nhiều nhà phát triển Java, về cơ bản, thư viện cửa sổ duy nhất có sẵn. Trong một cái gì đó như C ++, có hàng tá thư viện cửa sổ, khung ứng dụng, v.v., mỗi cái có một sự thỏa hiệp riêng giữa dễ sử dụng so với thực thi nhanh, giao diện nhất quán và cảm nhận so với giao diện tự nhiên, v.v. Điểm gắn bó thực sự duy nhất là một số (ví dụ Qt) có thể khá đắt (ít nhất là cho mục đích thương mại).
Thứ ba rất nhiều mã được viết bằng C ++ (và C thậm chí còn hơn thế) đơn giản là cũ hơn và trưởng thành hơn. Rất nhiều trong số đó chứa cốt lõi của các thói quen được viết từ nhiều thập kỷ trước, khi dành thêm thời gian để tối ưu hóa mã là hành vi bình thường, được mong đợi. Điều đó thường có một lợi ích thực sự trong mã đó nhỏ hơn và nhanh hơn. C ++ (hoặc C) nhận được tín dụng cho mã nhỏ và nhanh, nhưng nó thực sự là một sản phẩm của nhà phát triển và các ràng buộc về thời gian mã được viết. Ở một mức độ nào đó, điều này dẫn đến một lời tiên tri tự hoàn thành - khi mọi người quan tâm đến tốc độ, họ thường chọn C ++ vì nó có danh tiếng đó. Họ đặt thêm thời gian và nỗ lực để tối ưu hóa, và một thế hệ mã C ++ nhanh mới được viết.
Tóm lại, việc triển khai Java bình thường khiến tối ưu hóa tối đa có vấn đề. Tồi tệ hơn, nơi Java hiển thị , những thứ như bộ công cụ cửa sổ và thời gian khởi động JVM thường đóng vai trò lớn hơn tốc độ thực thi của chính ngôn ngữ. Trong rất nhiều trường hợp, C và C ++ cũng nhận được tín dụng cho những gì thực sự là sản phẩm của việc đơn giản hóa làm việc chăm chỉ hơn để tối ưu hóa.
Đối với câu hỏi thứ hai, tôi nghĩ phần lớn là vấn đề bản chất của con người trong công việc. Một vài người quá khích đưa ra những tuyên bố khá thổi phồng về việc Java nhanh chóng bị làm mờ. Ai đó thử nó và thấy rằng ngay cả một chương trình tầm thường cũng mất vài giây để bắt đầu, và cảm thấy chậm chạp và vụng về khi nó chạy. Rất ít người có thể bận tâm phân tích mọi thứ để nhận ra rằng phần lớn trong số này là thời gian khởi động của JVM và thực tế là khi họ lần đầu tiên thử mọi thứ, chưa có đoạn mã nào được biên dịch - một số mã đang được diễn giải, và một số được biên dịch trong khi họ chờ đợi. Tồi tệ hơn, ngay cả khi nó chạy đủ nhanh, giao diện thường sẽ có vẻ xa lạ và vụng về với hầu hết người dùng, vì vậy ngay cả khi các phép đo khách quan cho thấy thời gian phản hồi nhanh, nó vẫn có vẻ vụng về.
Thêm những thứ đó lại với nhau dẫn đến một phản ứng khá đơn giản và tự nhiên: Java chậm chạp, xấu xí và vụng về. Với sự cường điệu nói rằng nó thực sự rất nhanh, có xu hướng phản ứng thái quá và kết luận rằng nó chậm đến mức khủng khiếp , thay vì "chậm hơn một chút, và chủ yếu là trong những trường hợp cụ thể." Điều này nói chung là tồi tệ nhất đối với một nhà phát triển viết một vài chương trình đầu tiên bằng ngôn ngữ. Việc thực thi chương trình "hello world" trong hầu hết các ngôn ngữ xuất hiện tức thời, nhưng trong Java có một sự tạm dừng dễ nhận biết khi JVM khởi động. Ngay cả một trình thông dịch thuần túy chạy chậm hơn nhiều trên các vòng lặp chặt chẽ và như vậy vẫn sẽ thường xuất hiện nhanh hơn cho mã như thế này, đơn giản vì nó có thể được tải và bắt đầu thực thi sớm hơn một chút.