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

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

---

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

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

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

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

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

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

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

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

---

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

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

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

루비는 아마도 실시간 디지털 신호 처리 응용 프로그램이나 모든 종류의 실시간 제어 시스템을 작성하는 데 도움이되지 않을 것입니다. 루비 (오늘날 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 대 자바 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 is a vast improvement over 1.8. The biggest problems with Ruby 1.8 are its interpreted nature (no bytecode, no compilation) and that method calls, one of the most common operations in Ruby, are particularly slow.

It doesn't help that pretty much everything is a method lookup in Ruby - adding two numbers, indexing an array. Where other languages expose hacks (Python's __add__ method, Perl's overload.pm) Ruby does pure OO in all cases, and this can hurt performance if the compiler/interpreter is not clever enough.

If I were writing a popular web application in Ruby, my focus would be on caching. Caching a page reduces the processing time for that page to zero, whatever language you are using. For web applications, database overhead and other I/O begins to matter a lot more than the speed of the language, so I would focus on optimising that.

---

Writing code is slow. Reading code is slow. Finding and fixing bugs is slow. Adding features and enhancements is slow. Anything that improves on the previous is a win. Very rarely is execution performance an issue.

---

The answer is simple: people say ruby is slow because it is slow based on measured comparisons to other languages. Bear in mind, though, "slow" is relative. Often, ruby and other "slow" languages are plenty fast enough.

---

Joel on Software - Ruby Performance Revisited quite well explains it. Might be outdated though...

I would recommend to just stick with it as you're used to Ruby on Rails,
if you ever meet a performance issue you might reconsider to use a different language and framework.

In that case I would really suggest C# with ASP.NET MVC 2, works very well for CRUD apps.

---

I would say Ruby is slow because not much effort has been spent in making the interpreter faster. Same applies to Python. Smalltalk is just as dynamic as Ruby or Python but performs better by a magnitude, see http://benchmarksgame.alioth.debian.org. Since Smalltalk was more or less replaced by Java and C# (that is at least 10 years ago) no more performance optimization work had been done for it and Smalltalk is still ways faster than Ruby and Python. The people at Xerox Parc and at OTI/IBM had the money to pay the people that work on making Smalltalk faster. What I don't understand is why Google doesn't spend the money for making Python faster as they are a big Python shop. Instead they spend money on development of languages like Go...

---

First of all, do you care about what others say about the language you like? When it does the job it has to do, you're fine.

OO isn't the fastest way to execute code, but it does help in creating the code. Smart code is always faster than dumb code and useless loops. I'm an DBA and see a lot of these useless loops, drop them, use better code and queries and application is faster, much faster. Do you care about the last microsecond? You might have languages optimized for speed, others just do the job they have to do and can be maintained by many different programmers.

It's all just a choice.

---

Obviously, talking about speed Ruby loses. Even though benchmark tests suggest that Ruby is not so much slower than PHP. But in return, you are getting easy-to-maintain DRY code, the best out of all frameworks in various languages.

For a small project, you wont feel any slowness (I mean until like <50K users) given that no complex calculations are used in the code, just the mainstream stuff.

For a bigger project, paying for resources pays off and is cheaper than developer wages. In addition, writing code on RoR turns out to be much faster than any other.

In 2014 this magnitude of speed difference you're talking about is for most websites insignificant.

---

The way to deal with Ruby's performance in Web application is the same as with any other programming language:

ARCHITECTURE

This is easier to do in Rails than in most other Web Frameworks.

At the application level, by caching whatever is supposed to be cached and by managing the access to the DB in an intelligent way (since the bottleneck is usually on the "DB" access for most WEB apps).

Rails makes it very easy and natural to solve these problems. There are several abstractions for caching data, pages and fragments, and there are also very nice abstractions to deal with the SQL part in an optimised and reusable fashion (Active Record and AREL).

This is the reason why so many applications written in faster and not-so-expressive languages (like php) end up being slower than the Ruby counterparts. It's not so easy and elegant to tackle caching and querying with these languages than it is with Ruby.

At the infrastructure level it is reasonable to think of load balancing and all that stuff that I do not happen to know a lot about. I'd outsource that problem by hiring some platform as service provider, like Heroku or Engine Yard. Anyway. Deploying rails with load balancing is probably not very hard to do.

---

Ruby is slower than C++ at a number of easily measurable tasks (e.g., doing code that is heavily dependent on floating point). This is not very surprising, but enough justification for some people to say that “Ruby is Slow” without qualification. They don't count the fact that it is far easier and safer to write Ruby code than C++.

The best fix is to use targeted modules written in another language (e.g., C, C++, Fortran) in your Ruby code. Those can do the heavy lifting and your scripts can focus on higher level coordination issues.

---

Performance is almost always about good design and optimized database interactions. Ruby does what most web sites need quite fast, especially more recent versions; and the speed of development and ease of maintenance provides a large payoff in costs and in keeping customers happy. I find JAVA to have slow execution performance for some tasks, and given the difficulty of developing in JAVA, many developers create slow applications regardless of the theoretical speed capability as demonstrated in benchmarks (benchmarks are generally contrived to show a specific and narrow capability). When I need intensive processing that isn't well suited to my database's capabilities, I choose C or Objective-C or some other truly high performance compiled language for those tasks depending on the platform. If I need to create a databased web application, I use RoR or sometimes C# ASP.NET depending on other requirements; because all platforms have strengths and weaknesses. Execution speed of the things your application does is important, but after all, if execution performance of one narrow aspect of a language is all that counts; then I might still be using Assembler language for everything.

---

People say that Ruby is slow because they compare Ruby programs to programs written in other languages. Maybe the programs you write don't need to be faster. Maybe for the programs you write Ruby isn't the bottleneck that's slowing things down.

Ruby 2.1 compared to Javascript V8

Ruby 2.1 compared to ordinary Lua

Ruby 2.1 compared to Python 3

---

Ruby performs well for developer productivity. Ruby by nature forces test driven development because of the lack of types. Ruby performs well when used as a high level wrapper for C libraries. Ruby also performs well during long running processes when it is JIT-compiled to machine code via JVM or Rbx VM. Ruby does not perform well when it is required to crunch numbers in a short time with pure ruby code.

참고URL : https://stackoverflow.com/questions/2529852/why-do-people-say-that-ruby-is-slow