왜 사람들은 루비가 느리다고 말합니까?
저는 Ruby on Rails를 좋아하고 모든 웹 개발 프로젝트에 사용합니다.몇 년 전에 Rails가 메모리 호그라는 것과 어떻게 확장이 잘 안 되었는지에 대해 많은 이야기가 있었지만, Gregg Polk에 의해 이러한 제안이 받아들여졌습니다.
그런데 최근에 루비 자체가 느리다는 말을 많이 들었습니다.
- 왜 루비는 느리다고 생각하나요?
저는 루비가 느리다고 생각하지 않지만, 다시 말하지만, 저는 그것을 단순한 CRUD 앱과 회사 블로그를 만드는 데 사용하고 있습니다.루비가 느려지기 전에 어떤 종류의 프로젝트를 해야 할까요?아니면 이 느림이 단지 모든 프로그래밍 언어에 영향을 미치는 것입니까?
만약 당신이 이 "느림"을 처리하고 싶다면 루비 프로그래머로서 당신의 선택사항은 무엇입니까?
속도가 중요하고 트래픽이 많은 스택 오버플로와 같은 애플리케이션에 가장 적합한 루비 버전은 무엇입니까?
질문은 주관적이며, 아키텍처 설정(EC2 대 독립 실행형 서버 등)이 큰 차이를 가져온다는 것을 알고 있지만 루비가 느리다는 것에 대한 사람들의 의견을 듣고 싶습니다.
마지막으로, 저는 Ruby 2.0에 대한 많은 뉴스를 찾을 수 없습니다. - 그렇다면 우리는 그것으로부터 몇 년이나 떨어져 있는 것으로 알고 있습니다.
왜 루비는 느리다고 생각하나요?
왜냐하면 루비와 다른 언어 사이에서 일반적인 벤치마크를 실행하면 루비가 패배하기 때문입니다.
저는 루비가 느리다고 생각하지 않지만, 다시 말하지만, 저는 그것을 단순한 CRUD 앱과 회사 블로그를 만드는 데 사용하고 있습니다.루비가 느려지기 전에 어떤 종류의 프로젝트를 해야 할까요?아니면 이 느림이 단지 모든 프로그래밍 언어에 영향을 미치는 것입니까?
루비는 아마도 실시간 디지털 신호 처리 애플리케이션이나 어떤 종류의 실시간 제어 시스템을 작성하는 데 도움이 되지 않을 것입니다.Ruby(오늘날의 VM 포함)는 아마도 스마트폰과 같은 리소스가 제한된 컴퓨터에서 질식할 것입니다.
웹 애플리케이션의 많은 처리는 실제로 C.에서 개발된 소프트웨어(예: Apache, Thin, Nginx, SQLite, MySQL, Postgre)에 의해 수행됩니다.SQL, 많은 parsing library, RMagick, TCP/IP 등은 Ruby에서 사용하는 C 프로그램입니다.루비는 접착제와 비즈니스 논리를 제공합니다.
만약 당신이 이 "느림"을 처리하고 싶다면 루비 프로그래머로서 당신의 선택사항은 무엇입니까?
더 빠른 언어로 전환합니다.하지만 그것은 비용이 듭니다.그것은 가치가 있을지도 모르는 비용입니다.그러나 대부분의 웹 애플리케이션에서 언어 선택은 관련 요소가 아닙니다. 트래픽이 충분하지 않기 때문에 개발 비용이 훨씬 더 많이 드는 더 빠른 언어를 사용할 수 있습니다.
속도가 중요하고 트래픽이 많은 스택 오버플로와 같은 애플리케이션에 가장 적합한 루비 버전은 무엇입니까?
다른 사람들은 이렇게 대답했습니다. JRUby, IronRuby, RE는 애플리케이션의 Ruby 부분을 VM을 구입할 수 있는 플랫폼에서 더 빠르게 실행할 수 있도록 해줍니다. 그리고 종종 Ruby가 아닌 컴퓨터 시스템 아키텍처와 애플리케이션 아키텍처를 사용하기 때문에 데이터베이스 복제, 여러 애플리케이션 서버,역방향 프록시, HTTP 캐싱, memcache, Ajax, 클라이언트 측 캐싱 등을 사용한 로드 밸런싱.이 물건들은 루비가 아닙니다.
마지막으로, 저는 Ruby 2.0에 대한 많은 뉴스를 찾을 수 없습니다. - 그렇다면 우리는 그것으로부터 몇 년이나 떨어져 있는 것으로 알고 있습니다.
대부분의 사람들은 루비 1.9.1을 기다리고 있습니다.저 자신도 JRuby의 Ruby 1.9.1의 Rails 3.1을 기다리고 있습니다.
마지막으로, 많은 개발자들이 루비를 선택하는 이유는 프로그래밍이 다른 언어에 비해 더 즐거운 경험을 하게 해주고, 루비 위드 레일즈는 숙련된 웹 개발자들이 매우 빠르게 응용 프로그램을 개발할 수 있게 해주기 때문입니다.
우선, 무엇에 관해서는 더 느리죠?C? 파이썬?Computer Language Benchmarks Game에서 몇 가지 숫자를 알아보겠습니다.
- 루비 1.9 대 동일한 크기 순서 내의 Python3
- Ruby 1.9 대 동일한 크기 순서 내의 PHP
- Ruby 1.9와 Java 6 서버 비교 최대 2배 느림!
- 루비 1.9 대 C(gcc) 최대 2배 느림!
- ...
왜 루비는 느리다고 생각하나요?
누구에게 묻느냐에 따라 다릅니다.다음과 같은 말을 들을 수 있습니다.
- 루비는 해석된 언어이며 해석된 언어는 컴파일된 언어보다 느린 경향이 있습니다.
- Ruby는 가비지 컬렉션을 사용합니다(가비지 컬렉션도 사용하는 C#은 위의 더 알고리즘적이고 메모리 할당 집약적이지 않은 벤치마크에서 Ruby, Python, PHP 등보다 두 자릿수 앞서 나옵니다).
- 루비 메서드 호출은 느립니다(오리 타이핑 때문에 강력하게 타이핑된 해석 언어보다 확실히 빠름).
- Ruby(JRuby 제외)는 실제 멀티스레딩을 지원하지 않습니다.
- 기타.
하지만, 다시 말하지만, 무엇에 관해서는 느립니까?Ruby 1.9는 C(최대 300배 더 빠를 수 있음)와 비교했을 때 Python 및 PHP(3배 성능 요소 내)만큼 빠르기 때문에 위의 사항(애플리케이션이 이 측면에 크게 의존하는 경우 스레드 고려 사항 제외)은 대체로 학술적입니다.
만약 당신이 이 "느림"을 처리하고 싶다면 루비 프로그래머로서 당신의 선택사항은 무엇입니까?
확장성을 위해 쓰기를 수행하고 더 많은 하드웨어(예: 메모리) 사용
속도가 중요하고 트래픽이 많은 스택 오버플로와 같은 애플리케이션에 가장 적합한 루비 버전은 무엇입니까?
글쎄요, RE(Passenger와 결합)는 매우 좋은 후보가 될 것입니다.
Rails의 창시자인 David Heinmeier Hansson은 다음과 같이 말합니다.
Rails [Ruby]는 대부분의 웹 애플리케이션에 적합합니다.매일 수백만 건의 동적 페이지뷰를 수행하는 사이트가 있습니다.만약 당신이 야후나 아마존의 첫 페이지에 있게 된다면, 어떤 언어로 된 틀도 당신에게 큰 도움이 될 것 같지 않습니다.당신은 아마도 당신 자신의 것을 굴려야 할 것입니다.하지만 물론 CPU 사이클도 무료로 사용하고 싶습니다.저는 자유 개발자 주기에 훨씬 더 관심이 많고 전자를 후자와 바꿀 의향이 있습니다.
즉, 더 많은 하드웨어나 기계를 문제에 투입하는 것이 더 많은 개발자를 고용하고 더 빠른 속도로 언어를 유지하는 것보다 더 저렴합니다.결국, C에서 웹 애플리케이션을 작성하는 사람은 거의 없습니다.
Ruby 1.9는 1.8보다 훨씬 향상되었습니다.Ruby 1.8의 가장 큰 문제는 해석된 특성(바이트코드 없음, 컴파일 없음)이며 Ruby에서 가장 일반적인 작업 중 하나인 메서드 호출이 특히 느립니다.
거의 모든 것이 루비에서 두 개의 숫자를 추가하고 배열을 인덱싱하는 메소드 검색이라는 것은 도움이 되지 않습니다.다른 언어가 해킹을 노출하는 경우(Python's)__add__method,.pm ) 시킬 수 있습니다.", Perl's overload.pm ) Ruby의 ▁) 에서 OO을 사용하는 경우와 동일한 방법을 사용하는 경우가 .
만약 내가 루비에서 인기 있는 웹 애플리케이션을 쓰고 있다면, 나는 캐싱에 집중할 것입니다.페이지를 캐시하면 사용 중인 언어에 관계없이 해당 페이지의 처리 시간이 0으로 줄어듭니다.웹 애플리케이션의 경우 데이터베이스 오버헤드 및 기타 I/O가 언어 속도보다 훨씬 더 중요해지기 시작하므로 이를 최적화하는 데 중점을 둡니다.
코드 작성 속도가 느립니다.코드 판독 속도가 느립니다.버그를 찾아 고치는 것은 느립니다.기능 및 향상된 기능을 추가하는 속도가 느립니다.이전보다 개선되는 것은 모두 승리입니다.실행 성능이 문제가 되는 경우는 거의 없습니다.
답은 간단합니다: 사람들은 루비가 다른 언어와 비교했을 때 느리기 때문에 느리다고 말합니다.하지만, "느림"은 상대적이라는 것을 명심하세요.종종, 루비와 다른 "느린" 언어들은 충분히 빠릅니다.
Joel on Software - Ruby Performance Reviewed는 그것을 꽤 잘 설명합니다.시대에 뒤떨어질 수도 있지만,
온.
성능 문제가 발생하면 다른 언어와 프레임워크를 사용하는 것을 다시 고려할 수 있습니다.
그렇다면 저는 정말로 ASP.NET MVC 2가 있는 C#을 제안하고 싶습니다. 이것은 CRUD 앱에 매우 잘 작동합니다.
루비는 통역사를 더 빨리 만드는 데 많은 노력을 기울이지 않았기 때문에 느리다고 생각합니다.Python도 마찬가지입니다.Smalltalk는 Ruby 또는 Python만큼 동적이지만 성능이 훨씬 우수합니다. http://benchmarksgame.alioth.debian.org 을 참조하십시오.Smalltalk가 Java 및 C#(최소 10년 전)으로 대체되었기 때문에 성능 최적화 작업은 더 이상 수행되지 않았으며 Smalltalk는 여전히 Ruby 및 Python보다 훨씬 빠릅니다.제록스 파크와 OTI/IBM의 사람들은 Smalltalk를 더 빨리 만드는 일을 하는 사람들에게 돈을 지불할 돈이 있었습니다.제가 이해할 수 없는 것은 왜 구글이 파이썬을 더 빠르게 만드는 데 돈을 쓰지 않는지입니다. 파이썬은 큰 상점이기 때문입니다.대신에 그들은 바둑과 같은 언어 개발에 돈을 씁니다...
Ruby는 쉽게 측정할 수 있는 여러 작업(예: 부동소수점에 크게 의존하는 코드 수행)에서 C++보다 느립니다.이것은 그다지 놀랍지는 않지만, 일부 사람들이 자격 없이 "루비는 느리다"라고 말할 충분한 정당성이 있습니다.그들은 루비 코드를 작성하는 것이 C++보다 훨씬 쉽고 안전하다는 사실을 고려하지 않습니다.
가장 좋은 해결책은 루비 코드에서 다른 언어(예: C, C++, Fortran)로 작성된 대상 모듈을 사용하는 것입니다.이들은 힘든 작업을 수행할 수 있으며 스크립트는 더 높은 수준의 조정 문제에 집중할 수 있습니다.
우선, 여러분은 여러분이 좋아하는 언어에 대해 다른 사람들이 말하는 것에 관심이 있나요?그것이 해야 할 일을 할 때, 당신은 괜찮습니다.
OOO가 코드를 실행하는 가장 빠른 방법은 아니지만 코드를 만드는 데 도움이 됩니다.스마트 코드는 항상 멍청한 코드와 쓸모없는 루프보다 빠릅니다.저는 DBA입니다. 쓸모없는 루프를 많이 보고, 루프를 삭제하고, 더 나은 코드와 쿼리를 사용하고, 애플리케이션이 훨씬 빠릅니다.마지막 마이크로초가 신경쓰이나요?여러분은 속도에 최적화된 언어를 가지고 있을 수도 있고, 다른 언어들은 그들이 해야 할 일만 하고 많은 다른 프로그래머들에 의해 유지될 수 있습니다.
모두 선택일 뿐입니다.
분명히, 속도에 대해 이야기하는 것은 루비가 지는 것입니다.비록 벤치마크 테스트에서 Ruby가 PHP보다 그렇게 느리지 않다는 것을 보여줍니다.그러나 그 대가로 다양한 언어로 된 프레임워크 중에서 가장 우수한 DRY 코드를 쉽게 유지할 수 있습니다.
소규모 프로젝트의 경우 코드에 복잡한 계산이 사용되지 않고 메인스트림 항목만 사용된다는 점을 고려할 때 속도가 느려지는 것을 느끼지 못할 것입니다.
더 큰 프로젝트의 경우, 자원에 대한 비용을 지불하는 것은 효과가 있고 개발자 임금보다 저렴합니다.게다가, RoR에 코드를 쓰는 것은 다른 어떤 것보다 훨씬 빠른 것으로 밝혀졌습니다.
2014년에 말씀하신 속도 차이의 크기는 대부분의 웹 사이트에서 미미합니다.
웹 애플리케이션에서 Ruby의 성능을 처리하는 방법은 다른 프로그래밍 언어와 동일합니다.
건축
대부분의 다른 웹 프레임워크보다 레일에서 이 작업을 수행하기가 더 쉽습니다.
애플리케이션 레벨에서 캐슁하는 모든 항목을 캐싱하고 지능적인 방식으로 DB에 대한 액세스를 관리합니다(대부분의 WEB 애플리케이션의 경우 병목 현상이 "DB" 액세스에 있기 때문).
레일즈는 이러한 문제를 매우 쉽고 자연스럽게 해결할 수 있도록 합니다.데이터, 페이지 및 조각을 캐싱하기 위한 몇 가지 추상화가 있으며, SQL 부분을 최적화되고 재사용 가능한 방식으로 처리하기 위한 매우 좋은 추상화도 있습니다(Active Record 및 AREL).
이것이 바로 더 빠르고 표현력이 그리 높지 않은 언어(예: php)로 작성된 많은 응용 프로그램이 Ruby의 응용 프로그램보다 더 느리게 되는 이유입니다.이러한 언어로 캐싱과 쿼리를 처리하는 것은 Ruby보다 쉽고 우아하지 않습니다.
인프라 수준에서는 로드 밸런싱과 제가 잘 알지 못하는 모든 것을 고려하는 것이 합리적입니다.저는 Heroku나 Engine Yard와 같은 플랫폼을 서비스 공급자로 고용함으로써 그 문제를 아웃소싱할 것입니다.어쨌든.로드 밸런싱을 사용하여 레일을 배치하는 것은 아마도 그리 어렵지 않을 것입니다.
사람들은 루비 프로그램을 다른 언어로 쓰여진 프로그램과 비교하기 때문에 루비가 느리다고 말합니다.작성하는 프로그램이 더 빠를 필요는 없습니다.아마도 당신이 쓰는 프로그램의 경우 루비는 속도를 늦추는 병목 현상이 아닐 것입니다.
성능은 거의 항상 우수한 설계와 최적화된 데이터베이스 상호 작용에 관한 것입니다.Ruby는 대부분의 웹 사이트, 특히 최신 버전에 필요한 작업을 매우 빠르게 수행합니다. 개발 속도와 유지보수 용이성은 비용과 고객 만족도를 높여줍니다.JAVA는 일부 작업에 대해 실행 성능이 느리고, JAVA에서 개발하는 데 어려움이 있기 때문에 많은 개발자들이 벤치마크에서 보여준 이론적인 속도 능력에 관계없이 느린 애플리케이션을 만듭니다(벤치마크는 일반적으로 특정하고 좁은 기능을 보여주기 위해 고안되었습니다).데이터베이스 기능에 적합하지 않은 집중적인 처리가 필요할 때는 플랫폼에 따라 C 또는 Objective-C 또는 기타 진정한 고성능 컴파일 언어를 선택합니다.데이터베이스 웹 애플리케이션을 만들어야 하는 경우에는 다른 요구 사항에 따라 RoR 또는 C# ASP.NET을 사용합니다. 모든 플랫폼에는 장단점이 있기 때문입니다.응용 프로그램이 수행하는 작업의 실행 속도도 중요하지만, 결국 언어의 좁은 측면의 실행 성능만 중요하다면, 저는 여전히 모든 작업에 어셈블러 언어를 사용하고 있을 수도 있습니다.
루비는 개발자의 생산성을 위해 좋은 성과를 내고 있습니다.루비는 본질적으로 유형이 부족하기 때문에 테스트 주도 개발을 강요합니다.Ruby는 C 라이브러리의 고급 래퍼로 사용할 때 성능이 좋습니다.또한 Ruby는 JVM 또는 Rbx VM을 통해 JIT를 머신 코드로 컴파일할 때 장시간 실행되는 프로세스에서도 우수한 성능을 발휘합니다.Ruby는 순수한 Ruby 코드로 짧은 시간 내에 숫자를 처리해야 하는 경우에는 성능이 좋지 않습니다.
언급URL : https://stackoverflow.com/questions/2529852/why-do-people-say-that-ruby-is-slow
'programing' 카테고리의 다른 글
| Firebase 스토리지에서 전체 폴더를 다운로드하는 방법은 무엇입니까? (0) | 2023.06.07 |
|---|---|
| web.xml이 누락되었으며 true로 설정되었습니다. (0) | 2023.06.02 |
| 안드로이드 앱의 릴리스 버전을 구축하기 전에 디버그 로깅 호출을 모두 제거하는 방법은 무엇입니까? (0) | 2023.06.02 |
| 유닉스 타임스탬프(에포크 이후 초)를 루비 날짜 시간으로 변환하는 방법은 무엇입니까? (0) | 2023.06.02 |
| 개체를 해시로 루비 변환 (0) | 2023.06.02 |