4 ms·

The performance of Rails serializers is still a nightmare. God awful performance.

by Rapzid 3y ago

crystaln 3y ago
20 years on… “Just use another framework when you need performance” they say.
- Rapzid 3y ago
  Also 20 years on the http client still doesn't have proper timeouts.
berkes 3y ago
> The performance of Rails serializers is still a nightmare Well, The performance of Ruby is still a nightmare. Not just serializers. It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible. But really. Just try anything cpu-bound (e.g. transform a huge list or CSV or so), and the lack of native, safe, threading, the horrendous performance of both the JIT compiler and the runtime and the language become apparent. This isn't to criticize Ruby. Because once you see all the runtime inflection, the way it can modify itself runtime and the DSL magic it allows, the current performance is a magnificent feat! It should be impossible to have it perform at all, given these features. That people managed to make such a beautiful language, with such marvelous features and still have it perform like it does, is a true engineering marvel.
- throwthrow5643 3y ago
  > It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible. Sorry, what other interpreted language has significantly better serializiation/deserialization performance than Ruby?
  - berkes 3y ago
    Python, PHP and JavaScript have significantly better performance for cpu-bound programs. E.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ruby-php.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... And I have measured ser/de for PHP, Ruby (and Rust, we needed to know how much faster JSON serde in rust would be, and compared it to Ruby and PHP). Php is probably much faster because the JSON ser/de is apparently written in C.
throwthrow5643 3y ago
I remember looking at BSON de/serializers for some perceived performance issue a while back, ruby was only marginally slower than PHP for the same task, which was just pulling big record sets back from the db. Can you elaborate?
- hu3 3y ago
  When was that? I ask because PHP made large improvements to performance in the last few years. Sometimes it's more than 2x faster than before. They now have JIT and are planing to have an intermediate language for even more speed. Most PHP stdlib code is pure C/C++ so it tends to be very fast, but I'm guessing Ruby is the same.
  - throwthrow5643 3y ago
    It was about maybe late last year/Jan this year. When you say intermediate language, do you mean PHP has a bytecode interpreter instead of AST? At the time I looked at it, to convince myself there was no issue with Ruby, I actually hooked up the same table/query to PHP and used PHP's excellent profiling tools, then compared those to the Rails profiler. There wasn't a great difference. PHP was faster sure, but there was definitely no knocking Ruby's speed.

The performance of Rails serializers is still a nightmare. God awful performance.

by Rapzid 3y ago

The performance of Rails serializers is still a nightmare. God awful performance.

crystaln 3y ago

20 years on… “Just use another framework when you need performance” they say.

Rapzid 3y ago
Also 20 years on the http client still doesn't have proper timeouts.

berkes 3y ago

> The performance of Rails serializers is still a nightmare Well, The performance of Ruby is still a nightmare. Not just serializers. It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible. But really. Just try anything cpu-bound (e.g. transform a huge list or CSV or so), and the lack of native, safe, threading, the horrendous performance of both the JIT compiler and the runtime and the language become apparent. This isn't to criticize Ruby. Because once you see all the runtime inflection, the way it can modify itself runtime and the DSL magic it allows, the current performance is a magnificent feat! It should be impossible to have it perform at all, given these features. That people managed to make such a beautiful language, with such marvelous features and still have it perform like it does, is a true engineering marvel.

throwthrow5643 3y ago
> It's that serializers in Rails are the most prominent place where you'll have cpu-bound performance made visible. Sorry, what other interpreted language has significantly better serializiation/deserialization performance than Ruby?
- berkes 3y ago
  Python, PHP and JavaScript have significantly better performance for cpu-bound programs. E.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/ruby-php.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... And I have measured ser/de for PHP, Ruby (and Rust, we needed to know how much faster JSON serde in rust would be, and compared it to Ruby and PHP). Php is probably much faster because the JSON ser/de is apparently written in C.

throwthrow5643 3y ago

I remember looking at BSON de/serializers for some perceived performance issue a while back, ruby was only marginally slower than PHP for the same task, which was just pulling big record sets back from the db. Can you elaborate?

hu3 3y ago
When was that? I ask because PHP made large improvements to performance in the last few years. Sometimes it's more than 2x faster than before. They now have JIT and are planing to have an intermediate language for even more speed. Most PHP stdlib code is pure C/C++ so it tends to be very fast, but I'm guessing Ruby is the same.
- throwthrow5643 3y ago
  It was about maybe late last year/Jan this year. When you say intermediate language, do you mean PHP has a bytecode interpreter instead of AST? At the time I looked at it, to convince myself there was no issue with Ruby, I actually hooked up the same table/query to PHP and used PHP's excellent profiling tools, then compared those to the Rails profiler. There wasn't a great difference. PHP was faster sure, but there was definitely no knocking Ruby's speed.