4 ms·

Don't use Ruby if performance counts. It's that simple.

by ahoka 10y ago

rubyn00bie 10y ago
I disagree but perhaps it's on semantics... A better statement would be: If the boxing/unboxing matters, don't use a language with objects. Use one that gives you value types to manipulate and serialize into. For some things, like Regexp, the language has almost zero overhead-- because it's done in C/bare metal. Additionally you could provide which languages/runtimes one should use.
astrodust 10y ago
Don't make comments like this if you don't understand why people use Ruby in the first place. Maybe your code is performing acceptably well, but if someone comes up to you and says "Hey, would you like some free performance with this drop-in replacement?" you'd be stupid to say no. There's a difference between performance being critical and performance being important.
vinceguidry 10y ago
Performance actually matters a lot in Ruby. The average coder doesn't (usually) have to deal with it, but chasing down performance issues in library code opens up more and more applications for Ruby to tackle. It would be awesome if Ruby could eventually become useful in every context. I think it'll eventually get there, but on the way there will need a mountain of performance improvements.
- Xylakant 10y ago
  I don't think ruby will ever get to the point where it's useful or a good fit in every context. The optimization goals are pretty clearly laid out: developer performance and happiness over raw speed of the language. A lot of features don't lend themselves to easy performance optimization (open classes, the ability to change methods on individual objects, lots of the metaprogramming features etc.). It's just not ruby's goal to be fast on every platform and in every context. It's often fast enough, though.
  - whistlerbrk 10y ago
    I agree that Ruby isn't a good fit for every context, but the reasons for Ruby's speed can and are being addressed, this article is extremely accessible and beautiful: http://chrisseaton.com/rubytruffle/deoptimizing/ http://chrisseaton.com/rubytruffle/deoptimizing/ A few critical C extensions are missing (OpenSSL): https://github.com/graalvm/truffleruby https://github.com/graalvm/truffleruby A recent benchmark (FWIW): https://pragtob.wordpress.com/2017/01/24/benchmarking-a-go-ai-in-ruby-cruby-vs-rubinius-vs-jruby-vs-truffle-a-year-later/ https://pragtob.wordpress.com/2017/01/24/benchmarking-a-go-a...
- tmat 10y ago
  concurrency will always limit ruby.. it will never ever get there and that's ok because that's not ruby's goal.
  - lloeki 10y ago
    Ruby (MRI) is perfectly concurrent already, it just sucks at parallelism.
  - astrodust 10y ago
    Ruby has some of the best concurrency support: Fibers and threads are all well-established features. JRuby and Rubinius can handle native threads, no Global Interpreter Lock (GIL) at all. The downside is most Ruby code bases are reluctant to take advantage of it, or even be thread-safe or fiber-aware, which can make writing apps more challenging than an environment like Node.js where there's established standards and expectations.
    - MrBra 10y ago
      Also let's not forget about Guilds... http://olivierlacan.com/posts/concurrency-in-ruby-3-with-guilds/ http://olivierlacan.com/posts/concurrency-in-ruby-3-with-gui...
ciconia 10y ago
Performance is only one of several factors when selecting a programming language, like suitability to problem domain, available libraries, tooling etc. In my work I have found Ruby often more than makes up for its poor performance record with an excellent ecosystem, mature testing tools, and outstanding string processing APIs. It also offers a high fun factor, which is just as important IMHO.
pmontra 10y ago
I remember a Rails application I developed a couple of years ago. Basically a JS dashboard over a time series database, but not a SPA. Let's say a few JS-fat pages displaying graphs with filters. The JS code in the pages made API calls to the Rails controllers which answer in JSON. Plus, we had some cron jobs pulling JSON data from a remote API. The application was fast enough but the data transfer started to dominate response time when the queries were large. We did several optimizations to reduce the size of the JSON (gzip among them, obviously) and sometimes building the JSON manually instead of using the jbuilder provided a speedup. The cron jobs were OK. Using oj made a noticeable difference over the default parser. Batch inserts in the db made a big difference too (the activerecord-import gem). With those optimizations there was no need to write everything else in a more performant language. After all, oj and batch inserts already moved most of our performance critical code from Ruby to C.

Don't use Ruby if performance counts. It's that simple.

by ahoka 10y ago

Don't use Ruby if performance counts. It's that simple.

I disagree but perhaps it's on semantics... A better statement would be: If the boxing/unboxing matters, don't use a language with objects. Use one that gives you value types to manipulate and serialize into. For some things, like Regexp, the language has almost zero overhead-- because it's done in C/bare metal. Additionally you could provide which languages/runtimes one should use.

astrodust 10y ago

Don't make comments like this if you don't understand why people use Ruby in the first place. Maybe your code is performing acceptably well, but if someone comes up to you and says "Hey, would you like some free performance with this drop-in replacement?" you'd be stupid to say no. There's a difference between performance being critical and performance being important.

vinceguidry 10y ago

Performance actually matters a lot in Ruby. The average coder doesn't (usually) have to deal with it, but chasing down performance issues in library code opens up more and more applications for Ruby to tackle. It would be awesome if Ruby could eventually become useful in every context. I think it'll eventually get there, but on the way there will need a mountain of performance improvements.

Xylakant 10y ago
I don't think ruby will ever get to the point where it's useful or a good fit in every context. The optimization goals are pretty clearly laid out: developer performance and happiness over raw speed of the language. A lot of features don't lend themselves to easy performance optimization (open classes, the ability to change methods on individual objects, lots of the metaprogramming features etc.). It's just not ruby's goal to be fast on every platform and in every context. It's often fast enough, though.
- whistlerbrk 10y ago
  I agree that Ruby isn't a good fit for every context, but the reasons for Ruby's speed can and are being addressed, this article is extremely accessible and beautiful: http://chrisseaton.com/rubytruffle/deoptimizing/ http://chrisseaton.com/rubytruffle/deoptimizing/ A few critical C extensions are missing (OpenSSL): https://github.com/graalvm/truffleruby https://github.com/graalvm/truffleruby A recent benchmark (FWIW): https://pragtob.wordpress.com/2017/01/24/benchmarking-a-go-ai-in-ruby-cruby-vs-rubinius-vs-jruby-vs-truffle-a-year-later/ https://pragtob.wordpress.com/2017/01/24/benchmarking-a-go-a...
tmat 10y ago
concurrency will always limit ruby.. it will never ever get there and that's ok because that's not ruby's goal.
- lloeki 10y ago
  Ruby (MRI) is perfectly concurrent already, it just sucks at parallelism.
- astrodust 10y ago
  Ruby has some of the best concurrency support: Fibers and threads are all well-established features. JRuby and Rubinius can handle native threads, no Global Interpreter Lock (GIL) at all. The downside is most Ruby code bases are reluctant to take advantage of it, or even be thread-safe or fiber-aware, which can make writing apps more challenging than an environment like Node.js where there's established standards and expectations.
  - MrBra 10y ago
    Also let's not forget about Guilds... http://olivierlacan.com/posts/concurrency-in-ruby-3-with-guilds/ http://olivierlacan.com/posts/concurrency-in-ruby-3-with-gui...

ciconia 10y ago

Performance is only one of several factors when selecting a programming language, like suitability to problem domain, available libraries, tooling etc. In my work I have found Ruby often more than makes up for its poor performance record with an excellent ecosystem, mature testing tools, and outstanding string processing APIs. It also offers a high fun factor, which is just as important IMHO.

pmontra 10y ago

I remember a Rails application I developed a couple of years ago. Basically a JS dashboard over a time series database, but not a SPA. Let's say a few JS-fat pages displaying graphs with filters. The JS code in the pages made API calls to the Rails controllers which answer in JSON. Plus, we had some cron jobs pulling JSON data from a remote API. The application was fast enough but the data transfer started to dominate response time when the queries were large. We did several optimizations to reduce the size of the JSON (gzip among them, obviously) and sometimes building the JSON manually instead of using the jbuilder provided a speedup. The cron jobs were OK. Using oj made a noticeable difference over the default parser. Batch inserts in the db made a big difference too (the activerecord-import gem). With those optimizations there was no need to write everything else in a more performant language. After all, oj and batch inserts already moved most of our performance critical code from Ruby to C.