사람들은 왜 루비가 느리다고 말합니까? [닫은]

Ruby on Rails를 좋아하며 모든 웹 개발 프로젝트에 사용합니다. 몇 년 전에 Rails가 메모리 호그 인 것에 대해 이야기하고 그것이 얼마나 잘 확장되지 않았는 지에 대해 많은 이야기가 있었지만 이러한 제안은 여기 Gregg Pollack에 의해 취해졌습니다 .

최근에 나는 루비 자체가 느리다는 사람들의 말을 듣고있다.

• 루비는 왜 느린 것으로 간주됩니까?

루비가 느리다는 것을 알지 못하지만 다시 간단한 CRUD 앱과 회사 블로그를 만드는 데 사용하고 있습니다. 루비가 느려지기 전에 어떤 종류의 프로젝트를해야합니까? 아니면이 느려짐이 모든 프로그래밍 언어에 영향을 미치는 것입니까?

• 이 "느림"을 처리하려면 Ruby 프로그래머가 선택할 수있는 옵션은 무엇입니까?

• 속도가 중요하고 트래픽이 많은 스택 오버플로와 같은 응용 프로그램에 가장 적합한 Ruby 버전은 무엇입니까?

질문은 주관적이며 아키텍처 설정 (EC2 대 독립형 서버 등)이 큰 차이를 만들지 만 사람들이 Ruby에 대해 느리게 생각하는 것을 듣고 싶습니다.

마지막으로, Ruby 2.0에 관한 뉴스를 많이 찾을 수 없습니다. 그로부터 몇 년이 지났다고 생각합니까?

루비는 왜 느린 것으로 간주됩니까?

Ruby와 다른 언어간에 일반적인 벤치 마크를 실행하면 Ruby가 손실됩니다.

루비가 느리다는 것을 알지 못하지만 다시 간단한 CRUD 앱과 회사 블로그를 만드는 데 사용하고 있습니다. 루비가 느려지기 전에 어떤 종류의 프로젝트를해야합니까? 아니면이 느려짐이 모든 프로그래밍 언어에 영향을 미치는 것입니까?

루비는 아마도 실시간 디지털 신호 처리 응용 프로그램이나 모든 종류의 실시간 제어 시스템을 작성하는 데 도움이되지 않을 것입니다. 루비 (오늘날 VM과 함께)는 아마도 스마트 폰과 같은 리소스가 제한된 컴퓨터에서 질식 할 것입니다.

웹 응용 프로그램의 많은 처리는 실제로 C로 개발 된 소프트웨어에 의해 수행됩니다. Apache, Thin, Nginx, SQLite, MySQL, PostgreSQL, 많은 파싱 라이브러리, RMagick, TCP / IP 등은 Ruby에서 사용하는 C 프로그램입니다. . 루비는 접착제와 비즈니스 로직을 제공합니다.

이 "느림"을 처리하려면 Ruby 프로그래머가 선택할 수있는 옵션은 무엇입니까?

더 빠른 언어로 전환하십시오. 그러나 비용이 든다. 그만한 가치가있는 비용입니다. 그러나 대부분의 웹 응용 프로그램의 경우 언어 선택은 관련 요소가 아닙니다. 개발에 더 많은 비용이 드는 더 빠른 언어를 사용하는 트래픽이 충분하지 않기 때문입니다.

속도가 중요하고 트래픽이 많은 스택 오버플로와 같은 응용 프로그램에 가장 적합한 Ruby 버전은 무엇입니까?

JRuby, IronRuby, REE는 VM을 감당할 수있는 플랫폼에서 애플리케이션의 루비 부분을 더 빨리 실행하게 할 것입니다. 느리게하는 것은 Ruby가 아니지만 컴퓨터 시스템 아키텍처 및 애플리케이션 아키텍처이므로 데이터베이스 복제, 다중 애플리케이션 서버, 리버스 프록시를 사용한로드 밸런싱, HTTP 캐싱, memcache, Ajax, 클라이언트 측 캐싱 등과 같은 작업을 수행 할 수 있습니다. 루비가 아닙니다.

마지막으로, Ruby 2.0에 관한 뉴스를 많이 찾을 수 없습니다. 그로부터 몇 년이 지났다고 생각합니까?

대부분의 사람들은 Ruby 1.9.1을 기다리고 있습니다. JRuby의 Ruby 1.9.1에서 Rails 3.1을 기다리고 있습니다.

마지막으로 많은 개발자들이 다른 언어에 비해 프로그래밍을보다 즐겁게 경험할 수 있고 Ruby with Rails를 통해 숙련 된 웹 개발자가 응용 프로그램을 매우 빠르게 개발할 수 있기 때문에 Ruby를 선택한다는 사실을 기억하십시오.

우선, 무엇과 관련하여 느리게 ? 씨? 파이썬? 의는하자 몇 가지 숫자를 얻을 상기 컴퓨터 언어 벤치 마크 게임 :

• 동일한 크기 의 루비 1.9 대 Python3
• 동일한 크기 의 루비 1.9 대 PHP
• 루비 1.9 대 Java 6 서버는 최대 2 배 더 느리다 !
• Ruby 1.9 vs. C (gcc) 최대 2 배 더 느리다 !
• ...

루비는 왜 느린 것으로 간주됩니까?

누구에게 물어 보느냐에 따라 다릅니다. 당신은 말할 수 있습니다 :

• 루비는 해석 된 언어 이며 해석 된 언어는 컴파일 된 언어보다 속도가 느린 경향이 있습니다.
• Ruby는 가비지 수집을 사용합니다 ( 가비지 수집 도 사용하는 C #은 위의 알고리즘을 사용하고 메모리를 많이 사용하지 않는 벤치 마크에서 Ruby, Python, PHP 등보다 2 배 빠릅니다).
• 루비 메소드 호출은 느리다 (덕 타이핑 때문에 강력하게 해석 된 언어보다 빠르다)
• Ruby (JRuby 제외) 는 진정한 멀티 스레딩을 지원하지 않습니다
• 기타

그러나 다시, 무엇에 관해서 천천히? Ruby 1.9는 C와 비교할 때 Python과 PHP (3 배 성능 요소 이내)만큼 빠르기 때문에 (최대 300 배 더 빠를 수 있음) 위의 사항 (스레딩 고려 사항을 제외하고 응용 프로그램이이 측면에 크게 의존하는 경우) )는 대부분 학문적입니다.

이 "느림"을 처리하려면 Ruby 프로그래머가 선택할 수있는 옵션은 무엇입니까?

확장 성을 위해 쓰고 더 많은 하드웨어를 던지십시오 (예 : 메모리)

속도가 중요하고 트래픽이 많은 스택 오버플로와 같은 응용 프로그램에 가장 적합한 Ruby 버전은 무엇입니까?

음, REE (결합 여객은 ) 아주 좋은 후보가 될 것입니다.

Rails의 제작자 David Heinemeier Hansson 이 말한 내용은 다음과 같습니다 .

Rails [Ruby]는 대부분의 웹 애플리케이션 Fast Enough를위한 것입니다. 하루에 수백만 건의 동적 페이지 조회를 수행하는 사이트가 있습니다. Yahoo 또는 Amazon 첫 페이지를 보게되면 어떤 언어로든 상용 프레임 워크가 당신에게 큰 도움이되지 않을 것입니다. 당신은 아마 자신의 롤을해야합니다. 그러나 물론 무료 CPU 사이클도 원합니다. 나는 단지 무료 개발자 사이클에 대해 훨씬 더 신경을 쓰며 전자를 후자에 교환하려고합니다.

즉, 문제에 더 많은 하드웨어 또는 기계를 던지는 것은 더 많은 개발자를 고용하고 더 빠르지 만 언어를 유지하기가 더 어려운 것보다 저렴합니다. 결국 C로 웹 애플리케이션을 작성하는 사람은 거의 없습니다.

Ruby 1.9는 1.8에 비해 크게 개선되었습니다. Ruby 1.8의 가장 큰 문제는 해석 된 특성 (바이트 코드 없음, 컴파일 없음)이며 Ruby에서 가장 일반적인 작업 중 하나 인 메소드 호출이 특히 느립니다.

그것은 거의 모든 것이 Ruby에서 메소드 조회라는 것을 도와주지 않습니다. 두 개의 숫자를 추가하고 배열을 색인화합니다. 다른 언어가 핵을 노출 __add__시키는 경우 (Python의 방법, Perl의 overload.pm) Ruby는 모든 경우에 순수 OO를 수행하므로 컴파일러 / 통역이 영리하지 않으면 성능이 저하 될 수 있습니다.

루비로 인기있는 웹 애플리케이션을 작성한다면, 캐싱에 중점을 둘 것입니다. 페이지를 캐시하면 사용중인 언어에 상관없이 해당 페이지의 처리 시간이 0으로 줄어 듭니다. 웹 응용 프로그램의 경우 데이터베이스 오버 헤드 및 기타 I / O가 언어 속도보다 훨씬 중요해지기 때문에이를 최적화하는 데 집중합니다.

코드 작성이 느립니다. 코드 읽기가 느립니다. 버그 찾기 및 수정이 느립니다. 기능 및 개선 사항 추가가 느립니다. 이전에 개선 된 것은 승리입니다. 실행 성능 문제는 거의 없습니다.

대답은 간단하다 : 사람들이이 때문에 루비가 느린라고 되어 속도가 느린 다른 언어로 측정 비교를 기반으로. 그러나 "느리게"는 상대적입니다. 종종 루비와 다른 "느린"언어는 충분히 빠릅니다.

Joel on Software-Ruby Performance Revisited에 설명되어 있습니다. 그래도 구식 일 수 있습니다 ...

Ruby on Rails에 익숙 할 때 그대로 사용하는 것이 좋습니다
. 성능 문제가 발생하면 다른 언어와 프레임 워크를 사용하는 것이 좋습니다.

이 경우 ASP.NET MVC 2를 사용하는 C #을 제안 하고 CRUD 앱에서 매우 잘 작동합니다.

나는 인터프리터를 더 빨리 만들기 위해 많은 노력을 기울이지 않았기 때문에 Ruby가 느리다고 말합니다. 파이썬에도 동일하게 적용됩니다. 스몰 토크는 루비 나 파이썬만큼이나 역동적이지만 성능이 훨씬 뛰어납니다 ( http://benchmarksgame.alioth.debian.org 참조) . 스몰 토크는 자바와 C # (적어도 10 년 전)으로 대체되었으므로 더 이상 성능 최적화 작업이 수행되지 않았으며 스몰 토크는 여전히 루비와 파이썬보다 훨씬 빠릅니다. Xerox Parc 및 OTI / IBM의 직원은 Smalltalk를보다 빠르게 수행하는 직원에게 비용을 지불했습니다. 내가 이해하지 못하는 것은 Google이 파이썬을 큰 파이썬 상점이기 때문에 더 빨리 파이썬을 만드는 데 돈을 쓰지 않는 이유입니다. 대신 그들은 Go와 같은 언어의 개발에 돈을 쓴다.

우선, 당신이 좋아하는 언어에 대해 다른 사람들의 말에 관심이 있습니까? 그것이해야 할 일을하면 괜찮습니다.

OO는 코드를 실행하는 가장 빠른 방법은 아니지만 코드 작성에 도움이됩니다. 스마트 코드는 항상 멍청한 코드와 쓸모없는 루프보다 빠릅니다. 나는 DBA이고 쓸모없는 루프를 많이보고, 삭제하고, 더 나은 코드와 쿼리를 사용하며 응용 프로그램이 더 빠르고 빠릅니다. 마지막 마이크로 초에 관심이 있습니까? 속도에 최적화 된 언어가있을 수도 있고, 다른 사람들은해야 할 일만하고 여러 프로그래머가 유지할 수 있습니다.

모두 선택에 불과합니다.

분명히 루비가 잃는 속도에 대해 이야기하십시오. 벤치 마크 테스트에서 루비가 PHP보다 그리 느리지 않음을 시사합니다. 그러나 그 대가로 다양한 언어로 된 모든 프레임 워크 중에서 가장 좋은 DRY 코드를 유지 관리하기가 쉬워지고 있습니다.

소규모 프로젝트의 경우 코드에서 복잡한 계산이 사용되지 않고 주류 일뿐이므로 사용자가 50K 미만이 될 때까지 느려질 것입니다.

더 큰 프로젝트의 경우 리소스 비용을 지불하면 개발자 임금보다 저렴합니다. 또한 RoR에 코드를 작성하는 것이 다른 것보다 훨씬 빠릅니다.

2014 년에 말한 속도 차이는 대부분의 웹 사이트에서 중요하지 않습니다.

웹 애플리케이션에서 Ruby의 성능을 처리하는 방법은 다른 프로그래밍 언어와 동일합니다.

건축물

이는 대부분의 다른 웹 프레임 워크보다 Rails에서 수행하는 것이 더 쉽습니다.

응용 프로그램 수준 에서 캐시되어야하는 모든 것을 캐싱하고 지능적인 방식으로 DB에 대한 액세스를 관리함으로써 (병목 현상은 일반적으로 대부분의 WEB 앱에 대한 "DB"액세스이므로)

Rails를 사용하면 이러한 문제를 매우 쉽고 자연스럽게 해결할 수 있습니다. 데이터, 페이지 및 조각 캐싱에 대한 몇 가지 추상화 가 있으며 SQL 파트를 최적화되고 재사용 가능한 방식 ( Active Record 및 AREL ) 으로 처리하기위한 추상화도 있습니다 .

이것이 PHP와 같이 표현이 빠르며 표현이 빠르지 않은 언어로 작성된 많은 응용 프로그램이 루비보다 더 느린 이유입니다. Ruby보다 캐싱 및 쿼리를 다루는 것이 그렇게 쉽고 우아하지 않습니다.

인프라 수준 에서는로드 밸런싱과 내가 알지 못하는 모든 것을 생각하는 것이 합리적입니다. Heroku 또는 Engine Yard 와 같은 서비스 제공 업체로 일부 플랫폼을 고용하여 해당 문제를 아웃소싱합니다 . 어쨌든. 로드 밸런싱으로 레일을 배포하는 것은 그리 어렵지 않습니다.

루비는 쉽게 측정 할 수있는 많은 작업 (예 : 부동 소수점에 크게 의존하는 코드 수행)에서 C ++보다 느립니다. 이것은 놀라운 일이 아니지만 일부 사람들이 자격없이“루비가 느리다”고 말할 수있는 충분한 근거입니다. 그들은 C ++보다 Ruby 코드를 작성하는 것이 훨씬 쉽고 안전하다는 사실을 계산하지 않습니다.

가장 좋은 해결책은 Ruby 코드에서 다른 언어로 작성된 대상 모듈 (예 : C, C ++, Fortran)을 사용하는 것입니다. 그것들은 힘든 일을 할 수 있고 스크립트는 더 높은 수준의 조정 문제에 집중할 수 있습니다.

성능은 거의 항상 우수한 디자인과 최적화 된 데이터베이스 상호 작용에 관한 것입니다. 루비는 대부분의 웹 사이트에서 특히 최신 버전이 필요한 작업을 매우 빠르게 수행합니다. 개발 속도와 유지 관리 편의성 덕분에 비용이 크게 증가하고 고객 만족도를 높일 수 있습니다. JAVA는 일부 작업의 실행 성능이 느리고 JAVA에서 개발하기가 어렵다는 점을 감안할 때 많은 개발자가 벤치 마크에서 입증 된 이론적 속도 기능에 관계없이 느린 응용 프로그램을 만듭니다 (벤치 마크는 일반적으로 구체적이고 좁은 기능을 보여주기 위해 고안되었습니다). 데이터베이스 기능에 적합하지 않은 집중적 인 처리가 필요한 경우 플랫폼에 따라 해당 작업에 C 또는 Objective-C 또는 다른 고성능 컴파일 언어를 선택합니다. 데이터베이스 웹 애플리케이션을 작성해야하는 경우 다른 요구 사항에 따라 RoR 또는 때로는 C # ASP.NET을 사용합니다. 모든 플랫폼에는 장단점이 있기 때문입니다. 응용 프로그램이 수행하는 작업의 실행 속도는 중요하지만 결국 언어의 좁은 측면 중 하나의 실행 성능이 중요한 경우입니다. 그때 나는 여전히 모든 것을 위해 어셈블러 언어를 사용하고있을 것입니다.

사람들은 Ruby 프로그램이 다른 언어로 작성된 프로그램과 비교하기 때문에 Ruby가 느리다고 말합니다. 작성하는 프로그램이 더 빠를 필요는 없습니다. 어쩌면 루비를 작성하는 프로그램이 병목 현상 을 일으키는 병목 현상 이 아닐 수도 있습니다.

Javascript V8과 비교 한 Ruby 2.1

루아 2.1과 일반 루아 비교

루비 2.1과 파이썬 3 비교

루비는 개발자 생산성을 위해 잘 수행합니다. 루비는 본질적으로 유형이 없기 때문에 테스트 주도 개발을 강요합니다. Ruby는 C 라이브러리를위한 고급 래퍼로 사용될 때 성능이 우수합니다. Ruby는 JVM 또는 Rbx VM을 통해 머신 코드로 JIT 컴파일 될 때 장기 실행 프로세스에서도 잘 수행됩니다. 순수한 루비 코드로 짧은 시간 내에 숫자를 크런치해야하는 경우 Ruby가 제대로 작동하지 않습니다.