Tại sao mọi người nói rằng Ruby chậm? [đóng cửa]

Tôi thích Ruby on Rails và tôi sử dụng nó cho tất cả các dự án phát triển web của mình. Một vài năm trước đây đã có rất nhiều thảo luận về Rails là một con heo bộ nhớ và khoảng cách không quy mô rất tốt nhưng các đề xuất này đã được đưa vào giường bởi Gregg Pollack đây .

Gần đây, tôi đã nghe mọi người nói rằng chính Ruby là chậm.

• Tại sao Ruby được coi là chậm?

Tôi không thấy Ruby bị chậm nhưng một lần nữa, tôi chỉ sử dụng nó để tạo các ứng dụng CRUD đơn giản và blog của công ty. Những loại dự án nào tôi cần phải thực hiện trước khi tôi thấy Ruby trở nên chậm chạp? Hay sự chậm chạp này chỉ là thứ gì đó ảnh hưởng đến tất cả các ngôn ngữ lập trình?

• Lựa chọn của bạn là một lập trình viên Ruby là gì nếu bạn muốn đối phó với "sự chậm chạp" này?

• Phiên bản nào của Ruby phù hợp nhất với một ứng dụng như Stack Overflow nơi tốc độ rất quan trọng và lưu lượng truy cập rất cao?

Các câu hỏi mang tính chủ quan và tôi nhận ra rằng thiết lập kiến ​​trúc (EC2 so với máy chủ độc lập, v.v.) tạo ra sự khác biệt lớn nhưng tôi muốn nghe mọi người nghĩ gì về Ruby bị chậm.

Cuối cùng, tôi không thể tìm thấy nhiều tin tức về Ruby 2.0 - Tôi có nghĩ rằng chúng ta sẽ cách đó vài năm không?

Tại sao Ruby được coi là chậm?

Bởi vì nếu bạn chạy điểm chuẩn điển hình giữa Ruby và các ngôn ngữ khác, Ruby sẽ thua.

Tôi không thấy Ruby bị chậm nhưng một lần nữa, tôi chỉ sử dụng nó để tạo các ứng dụng CRUD đơn giản và blog của công ty. Những loại dự án nào tôi cần phải thực hiện trước khi tôi thấy Ruby trở nên chậm chạp? Hay sự chậm chạp này chỉ là thứ gì đó ảnh hưởng đến tất cả các ngôn ngữ lập trình?

Ruby có thể sẽ không phục vụ bạn tốt khi viết một ứng dụng xử lý tín hiệu số thời gian thực hoặc bất kỳ loại hệ thống điều khiển thời gian thực nào. Ruby (với các máy ảo ngày nay) có thể sẽ bị nghẹt thở trên một máy tính bị hạn chế tài nguyên như điện thoại thông minh.

Hãy nhớ rằng rất nhiều việc xử lý trên các ứng dụng web của bạn thực sự được thực hiện bởi phần mềm được phát triển trong C. ví dụ: Apache, Thin, Nginx, SQLite, MySQL, PostgreQuery, nhiều thư viện phân tích cú pháp, RMagick, TCP / IP, v.v. . Ruby cung cấp keo và logic kinh doanh.

Lựa chọn của bạn là một lập trình viên Ruby là gì nếu bạn muốn đối phó với "sự chậm chạp" này?

Chuyển sang ngôn ngữ nhanh hơn. Nhưng điều đó mang một chi phí. Đó là một chi phí có thể có giá trị nó. Nhưng đối với hầu hết các ứng dụng web, lựa chọn ngôn ngữ không phải là một yếu tố có liên quan vì không có đủ lưu lượng truy cập biện minh cho việc sử dụng ngôn ngữ nhanh hơn có chi phí cao hơn nhiều để phát triển.

Phiên bản nào của Ruby phù hợp nhất với một ứng dụng như Stack Overflow nơi tốc độ rất quan trọng và lưu lượng truy cập rất cao?

Những người khác đã trả lời điều này - JRuby, IronRuby, REE sẽ làm cho phần Ruby trong ứng dụng của bạn chạy nhanh hơn trên các nền tảng có thể chi trả cho VM. Và vì thường không phải Ruby gây ra sự chậm chạp, mà là kiến ​​trúc hệ thống máy tính và kiến ​​trúc ứng dụng của bạn, bạn có thể thực hiện các công việc như sao chép cơ sở dữ liệu, nhiều máy chủ ứng dụng, cân bằng tải với proxy ngược, bộ nhớ cache HTTP, memcache, Ajax, bộ nhớ đệm phía máy khách, v.v. Không có thứ gì trong số này là Ruby.

Cuối cùng, tôi không thể tìm thấy nhiều tin tức về Ruby 2.0 - Tôi có nghĩ rằng chúng ta sẽ cách đó vài năm không?

Hầu hết mọi người đang chờ đợi Ruby 1.9.1. Bản thân tôi đang chờ Rails 3.1 trên Ruby 1.9.1 trên JRuby.

Cuối cùng, xin nhớ rằng rất nhiều nhà phát triển chọn Ruby vì nó giúp lập trình trải nghiệm vui vẻ hơn so với các ngôn ngữ khác và vì Ruby with Rails cho phép các nhà phát triển web lành nghề phát triển ứng dụng rất nhanh.

Trước hết, chậm hơn đối với những gì ? C? Con trăn? Chúng ta hãy lấy một số số tại Trò chơi Điểm chuẩn Ngôn ngữ Máy tính :

• Ruby 1.9 so với Python3 trong cùng một thứ tự cường độ
• Ruby 1.9 so với PHP trong cùng một thứ tự cường độ
• Máy chủ Ruby 1.9 so với Java 6 chậm hơn tới hai bậc !
• Ruby 1.9 so với C (gcc) chậm hơn tới hai bậc !
• ...

Tại sao Ruby được coi là chậm?

Phụ thuộc vào người mà bạn yêu cầu. Bạn có thể được nói rằng:

• Ruby là một ngôn ngữ được dịch và các ngôn ngữ được dịch sẽ có xu hướng chậm hơn các ngôn ngữ được biên dịch
• Ruby sử dụng bộ sưu tập rác (mặc dù C #, cũng sử dụng bộ sưu tập rác, đưa ra hai bậc độ lớn trước Ruby, Python, PHP, v.v. trong các tiêu chuẩn chuẩn hơn, ít phân bổ bộ nhớ hơn ở trên thuật toán)
• Các cuộc gọi phương thức Ruby rất chậm (mặc dù, do gõ vịt, chúng được cho là nhanh hơn so với các ngôn ngữ được gõ mạnh)
• Ruby (ngoại trừ JRuby) không hỗ trợ đa luồng thực sự
• Vân vân.

Nhưng, sau đó một lần nữa, chậm đối với những gì? Ruby 1.9 nhanh như Python và PHP (trong hệ số hiệu suất 3x) khi so sánh với C (có thể nhanh hơn tới 300 lần), do đó, ở trên (ngoại trừ các cân nhắc về luồng, ứng dụng của bạn phụ thuộc nhiều vào khía cạnh này ) phần lớn là học thuật.

Lựa chọn của bạn là một lập trình viên Ruby là gì nếu bạn muốn đối phó với "sự chậm chạp" này?

Viết cho khả năng mở rộng và ném thêm phần cứng vào nó (ví dụ như bộ nhớ)

Phiên bản nào của Ruby phù hợp nhất với một ứng dụng như Stack Overflow nơi tốc độ rất quan trọng và lưu lượng truy cập rất cao?

Chà, REE (kết hợp với Hành khách ) sẽ là một ứng cử viên rất tốt.

Đây là những gì người tạo ra Rails, David Heinemeier Hansson phải nói:

Rails [Ruby] dành cho phần lớn các ứng dụng web Fast Enough. Chúng tôi có các trang web thực hiện hàng triệu lượt xem trang động mỗi ngày. Nếu bạn kết thúc với trang nhất của Yahoo hoặc Amazon, không chắc rằng một khuôn khổ ngoài lề trong bất kỳ ngôn ngữ nào sẽ giúp bạn tốt hơn nhiều. Có lẽ bạn sẽ phải tự lăn. Nhưng chắc chắn, tôi cũng muốn chu kỳ CPU miễn phí. Tôi chỉ quan tâm nhiều hơn về các chu kỳ phát triển miễn phí và sẵn sàng đánh đổi cái trước cho cái sau.

tức là ném nhiều phần cứng hoặc máy móc vào vấn đề rẻ hơn so với việc thuê nhiều nhà phát triển hơn và sử dụng ngôn ngữ nhanh hơn, nhưng khó hơn để duy trì. Rốt cuộc, rất ít người viết các ứng dụng web bằng C.

Ruby 1.9 là một cải tiến lớn hơn 1.8. Các vấn đề lớn nhất với Ruby 1.8 là bản chất được giải thích của nó (không có mã byte, không biên dịch) và các cuộc gọi phương thức đó, một trong những hoạt động phổ biến nhất trong Ruby, đặc biệt chậm.

Nó không giúp được gì nhiều cho mọi thứ là một phương thức tra cứu trong Ruby - thêm hai số, lập chỉ mục một mảng. Trong trường hợp các ngôn ngữ khác phơi bày các bản hack ( __add__phương thức của Python , Perl'sload.pm) Ruby thực hiện OO thuần túy trong mọi trường hợp và điều này có thể ảnh hưởng đến hiệu suất nếu trình biên dịch / trình thông dịch không đủ thông minh.

Nếu tôi đang viết một ứng dụng web phổ biến trong Ruby, trọng tâm của tôi sẽ là bộ nhớ đệm. Bộ nhớ đệm một trang giúp giảm thời gian xử lý cho trang đó về 0, bất kể ngôn ngữ nào bạn đang sử dụng. Đối với các ứng dụng web, chi phí cơ sở dữ liệu và các I / O khác bắt đầu quan trọng hơn nhiều so với tốc độ của ngôn ngữ, vì vậy tôi sẽ tập trung vào việc tối ưu hóa điều đó.

Viết mã chậm. Đọc mã chậm. Tìm và sửa lỗi là chậm. Thêm các tính năng và cải tiến là chậm. Bất cứ điều gì cải thiện trước đó là một chiến thắng. Rất hiếm khi hiệu suất thực thi là một vấn đề.

Câu trả lời rất đơn giản: người ta nói ruby là chậm bởi vì nó là chậm dựa trên sự so sánh đo sang các ngôn ngữ khác. Mặc dù vậy, hãy nhớ rằng "chậm" là tương đối. Thông thường, ruby ​​và các ngôn ngữ "chậm" khác đủ nhanh.

Joel trên Phần mềm - Ruby Performance Revisited giải thích khá rõ về nó. Có thể đã lỗi thời mặc dù ...

Tôi khuyên bạn chỉ nên gắn bó với nó khi bạn đã quen với Ruby on Rails,
nếu bạn gặp phải vấn đề về hiệu suất, bạn có thể xem xét lại để sử dụng ngôn ngữ và khung khác.

Trong trường hợp đó tôi thực sự sẽ đề xuất C # với ASP.NET MVC 2 , hoạt động rất tốt cho các ứng dụng CRUD.

Tôi muốn nói rằng Ruby chậm vì không có nhiều nỗ lực để làm cho trình thông dịch nhanh hơn. Áp dụng tương tự cho Python. Smalltalk cũng năng động như Ruby hoặc Python nhưng hoạt động tốt hơn ở mức độ lớn, xem http://benchmarkgame.alioth.debian.org . Vì Smalltalk ít nhiều được thay thế bởi Java và C # (tức là ít nhất 10 năm trước), không có công việc tối ưu hóa hiệu suất nào được thực hiện cho nó và Smalltalk vẫn nhanh hơn Ruby và Python. Những người ở Xerox Parc và tại OTI / IBM đã có tiền để trả cho những người làm việc để làm cho Smalltalk nhanh hơn. Điều tôi không hiểu là tại sao Google không chi tiền để làm cho Python nhanh hơn vì chúng là một cửa hàng Python lớn. Thay vào đó, họ chi tiền cho việc phát triển các ngôn ngữ như Go ...

Trước hết, bạn có quan tâm đến những gì người khác nói về ngôn ngữ bạn thích không? Khi nó làm công việc nó phải làm, bạn ổn.

OO không phải là cách nhanh nhất để thực thi mã, nhưng nó giúp ích trong việc tạo mã. Mã thông minh luôn nhanh hơn mã câm và các vòng lặp vô dụng. Tôi là một DBA và thấy rất nhiều các vòng lặp vô dụng này, bỏ chúng đi, sử dụng mã tốt hơn và các truy vấn và ứng dụng nhanh hơn, nhanh hơn nhiều. Bạn có quan tâm đến micro giây cuối cùng không? Bạn có thể có ngôn ngữ được tối ưu hóa cho tốc độ, những ngôn ngữ khác chỉ làm công việc họ phải làm và có thể được duy trì bởi nhiều lập trình viên khác nhau.

Tất cả chỉ là một sự lựa chọn.

Rõ ràng, nói về tốc độ Ruby thua. Mặc dù các bài kiểm tra điểm chuẩn cho thấy Ruby không chậm hơn PHP nhiều. Nhưng bù lại, bạn đang nhận được mã DRY dễ bảo trì, tốt nhất trong số tất cả các khung bằng các ngôn ngữ khác nhau.

Đối với một dự án nhỏ, bạn sẽ không cảm thấy bất kỳ sự chậm chạp nào (ý tôi là cho đến khi thích <50K người dùng) cho rằng không có phép tính phức tạp nào được sử dụng trong mã, chỉ là công cụ chính.

Đối với một dự án lớn hơn, trả tiền cho các nguồn lực trả hết và rẻ hơn tiền lương của nhà phát triển. Ngoài ra, viết mã trên RoR hóa ra nhanh hơn nhiều so với bất kỳ loại nào khác.

Trong năm 2014, mức độ chênh lệch tốc độ mà bạn đang nói đến là dành cho hầu hết các trang web không đáng kể.

Cách đối phó với hiệu suất của Ruby trong ứng dụng Web cũng giống như với bất kỳ ngôn ngữ lập trình nào khác:

NGÀNH KIẾN TRÚC

Điều này dễ thực hiện trong Rails hơn trong hầu hết các Web Framework khác.

Ở cấp độ ứng dụng , bằng cách lưu vào bộ nhớ cache bất cứ thứ gì được cho là được lưu trong bộ nhớ cache và bằng cách quản lý quyền truy cập vào DB theo cách thông minh (vì nút cổ chai thường nằm trên quyền truy cập "DB" đối với hầu hết các ứng dụng WEB).

Rails làm cho nó rất dễ dàng và tự nhiên để giải quyết những vấn đề này. Có một số tóm tắt cho dữ liệu bộ nhớ cache, các trang và các đoạn , và cũng có những tóm tắt rất hay để xử lý phần SQL theo cách tối ưu hóa và có thể sử dụng lại ( Active Record và AREL ).

Đây là lý do tại sao rất nhiều ứng dụng được viết bằng các ngôn ngữ nhanh hơn và không biểu cảm (như php) cuối cùng lại chậm hơn so với các đối tác của Ruby. Thật không dễ dàng và thanh lịch để giải quyết bộ nhớ đệm và truy vấn bằng các ngôn ngữ này so với Ruby.

Ở cấp độ cơ sở hạ tầng , thật hợp lý khi nghĩ đến việc cân bằng tải và tất cả những thứ mà tôi không biết nhiều về nó. Tôi thuê ngoài vấn đề đó bằng cách thuê một số nền tảng làm nhà cung cấp dịch vụ, như Heroku hoặc Engine Yard . Dù sao. Triển khai đường ray với cân bằng tải có lẽ không khó thực hiện.

Ruby chậm hơn C ++ ở một số nhiệm vụ có thể đo lường dễ dàng (ví dụ: thực hiện mã phụ thuộc nhiều vào điểm nổi). Điều này không có gì đáng ngạc nhiên, nhưng đủ để biện minh cho một số người nói rằng Ruby Ruby là Slow chậm mà không cần bằng cấp. Họ không tính thực tế rằng việc viết mã Ruby dễ dàng và an toàn hơn nhiều so với C ++.

Cách khắc phục tốt nhất là sử dụng các mô-đun được nhắm mục tiêu được viết bằng ngôn ngữ khác (ví dụ: C, C ++, Fortran) trong mã Ruby của bạn. Những người có thể làm công việc nặng nhọc và kịch bản của bạn có thể tập trung vào các vấn đề phối hợp cấp cao hơn.

Hiệu suất hầu như luôn luôn là về thiết kế tốt và các tương tác cơ sở dữ liệu được tối ưu hóa. Ruby làm những gì hầu hết các trang web cần khá nhanh, đặc biệt là các phiên bản gần đây hơn; và tốc độ phát triển và dễ bảo trì cung cấp một khoản chi trả lớn trong chi phí và giữ cho khách hàng hài lòng. Tôi thấy JAVA có hiệu suất thực thi chậm đối với một số tác vụ và gặp khó khăn khi phát triển trong JAVA, nhiều nhà phát triển tạo ra các ứng dụng chậm bất kể khả năng tốc độ lý thuyết như thể hiện trong điểm chuẩn (điểm chuẩn thường được cho là khả năng cụ thể và hẹp). Khi tôi cần xử lý chuyên sâu không phù hợp với khả năng của cơ sở dữ liệu của mình, tôi chọn C hoặc Objective-C hoặc một số ngôn ngữ được biên dịch hiệu suất thực sự cao khác cho các tác vụ đó tùy thuộc vào nền tảng. Nếu tôi cần tạo một ứng dụng web có dữ liệu, Tôi sử dụng RoR hoặc đôi khi C # ASP.NET tùy thuộc vào các yêu cầu khác; bởi vì tất cả các nền tảng đều có điểm mạnh và điểm yếu. Tốc độ thực thi của những thứ mà ứng dụng của bạn thực hiện rất quan trọng, nhưng xét cho cùng, nếu hiệu suất thực thi của một khía cạnh hẹp của ngôn ngữ là tất cả những gì được tính; sau đó tôi có thể vẫn đang sử dụng ngôn ngữ Trình biên dịch cho mọi thứ.

Mọi người nói rằng Ruby chậm vì họ so sánh các chương trình của Ruby với các chương trình được viết bằng các ngôn ngữ khác. Có lẽ các chương trình bạn viết không cần phải nhanh hơn. Có thể đối với các chương trình bạn viết, Ruby không phải là nút cổ chai làm mọi thứ chậm lại.

Ruby 2.1 so với Javascript V8

Ruby 2.1 so với Lua thông thường

Ruby 2.1 so với Python 3

Ruby hoạt động tốt cho năng suất của nhà phát triển. Ruby do tự nhiên buộc phải phát triển theo hướng kiểm tra vì thiếu các loại. Ruby hoạt động tốt khi được sử dụng như một trình bao bọc cấp cao cho các thư viện C. Ruby cũng hoạt động tốt trong quá trình chạy dài khi được biên dịch JIT thành mã máy thông qua JVM hoặc Rbx VM. Ruby không hoạt động tốt khi được yêu cầu bẻ số trong một thời gian ngắn với mã ruby ​​thuần túy.