4 ms·

Curious if there’s anything public about improving ruby performance from the I/O angle mentioned in the post. Also interesting to see Mypyc, Pyre related AOT c

Curious if there’s anything public about improving ruby performance from the I/O angle mentioned in the post. Also interesting to see Mypyc, Pyre related AOT compiler (forget the name), and now this. Great to see! We’d gladly compile our code in CI if it meant better perf (already do for the UI stuff)

jez 5y ago
At the point where I/O is the performance bottleneck, that usually means it's not Ruby related! Instead, I/O problems are frequently a language-agnostic set of problems, like: - Oh jeez, I'm making a database roundtrip 2x more frequently than I'd like to! Maybe I should change my application to batch the database requests. - Oh jeez, I'm running on cheaper EC2 instances without SSDs, maybe I should upgrade! etc.
- notpachet 5y ago
  I've actually found that a lot of I/O bottlenecks are often Ruby related, for the fact that Ruby doesn't give you a lot of great options in terms of doing that I/O in a non-blocking way. If your Ruby program has to do things like fetch data from upstream via a network request, you have to be very careful not to cause request saturation / queueing if that upstream request starts timing out. Even a well-behaving upstream can cause problems if your user patterns require you to hit it a lot. Shopify was fortunate that we had a lot of spare money flying around and could just scale the shit out of things horizontally, but that's a crude solution. Granted, there's been a lot of interesting work done on Ruby concurrency lately, but it's far from a solved problem at the language level. (background: former Shopify EM)
ciconia 5y ago
> Curious if there’s anything public about improving ruby performance from the I/O angle mentioned in the post. I'm currently working on Polyphony [0], a Ruby gem for writing highly-concurrent Ruby apps. It uses Ruby fibers under the hood, and does I/O using io_uring (on Linux, there is also a libev-based backend). [0] https://github.com/digital-fabric/polyphony https://github.com/digital-fabric/polyphony
- joelbluminator 5y ago
  Interesting. > It uses Ruby fibers under the hood, I'm sure you are aware of ioquatix's work on Async/Falcon etc, how do you see your project differing from his work? And why hasn't anything changed in the Ruby server space - it's all processes and threads afaik.

jez 5y ago

At the point where I/O is the performance bottleneck, that usually means it's not Ruby related! Instead, I/O problems are frequently a language-agnostic set of problems, like: - Oh jeez, I'm making a database roundtrip 2x more frequently than I'd like to! Maybe I should change my application to batch the database requests. - Oh jeez, I'm running on cheaper EC2 instances without SSDs, maybe I should upgrade! etc.

notpachet 5y ago
I've actually found that a lot of I/O bottlenecks are often Ruby related, for the fact that Ruby doesn't give you a lot of great options in terms of doing that I/O in a non-blocking way. If your Ruby program has to do things like fetch data from upstream via a network request, you have to be very careful not to cause request saturation / queueing if that upstream request starts timing out. Even a well-behaving upstream can cause problems if your user patterns require you to hit it a lot. Shopify was fortunate that we had a lot of spare money flying around and could just scale the shit out of things horizontally, but that's a crude solution. Granted, there's been a lot of interesting work done on Ruby concurrency lately, but it's far from a solved problem at the language level. (background: former Shopify EM)

ciconia 5y ago

> Curious if there’s anything public about improving ruby performance from the I/O angle mentioned in the post. I'm currently working on Polyphony [0], a Ruby gem for writing highly-concurrent Ruby apps. It uses Ruby fibers under the hood, and does I/O using io_uring (on Linux, there is also a libev-based backend). [0] https://github.com/digital-fabric/polyphony https://github.com/digital-fabric/polyphony

joelbluminator 5y ago
Interesting. > It uses Ruby fibers under the hood, I'm sure you are aware of ioquatix's work on Async/Falcon etc, how do you see your project differing from his work? And why hasn't anything changed in the Ruby server space - it's all processes and threads afaik.