3 ms·

We have no plans to move to another Ruby implementation, primarily because Ruby itself is not yet a bottleneck for us.

ZenoArrow 10y ago
Is it something you'd consider? Even if it's not a performance bottleneck right now it's probably worth it to reduce server costs (more efficient Ruby implementation = fewer servers required to run GitLab.com). Could be looking at serious gains, 3x over CRuby looks to be a fairly reasonable goal when using RubyTruffle (slow startup times can be mitigated against with SubstrateVM), and if that's not an option due to it being a fairly new project, it seems like JRuby could give a decent performance boost too. https://pragtob.wordpress.com/2015/11/30/benchmarking-a-go-ai-in-ruby-cruby-vs-rubinius-vs-jruby-vs-trufflegraal/ https://pragtob.wordpress.com/2015/11/30/benchmarking-a-go-a... https://m.youtube.com/watch?v=wwEVakQzVAw https://m.youtube.com/watch?v=wwEVakQzVAw
- connorshea 10y ago
  JRuby isn't an option for us because we use too many gems, many of which have compatibility issues with JRuby's implementation of Ruby. This is especially a problem for gems with C extensions. I think Truffle is the most interesting new development in this realm, if it gets support for C extensions as they plan for it to, it may eventually be reasonable to run GitLab on it. That wouldn't be for a few more years though.
- YorickPeterse 10y ago
  There is no such thing as: 1. Replace Ruby implementation 2. ??? 3. Everything is 3x faster Whatever an implementation or product claims, it's just not possible. While we could benefit from not having a GIL (something Truffle has if I'm not mistaken), it's not a free trade-off. For example: * JRuby typically requires quite a bit more memory compared to CRuby, the same probably applies to Truffle * Dependencies might have to be replaced if they're written in C. I personally don't buy Truffle being able to support all extensions. It's super fucking hard. I spent a few years working on Rubinius and had the unfortunate experience of having to deal with C extensions a lot. Supporting these properly is really, really difficult. * JRuby might not work on all platforms we support. For example, we support Raspberry Pi's and the likes and it's not clear if JRuby would work there Most importantly of all: a large portion of our slowness is due to badly written SQL queries, code that hammers the database way too often, and our Git operations. None of this would be solved by switching to a different Ruby implementation. The only way to solve this is to: 1. Solve the code 2. Educate developers so they don't make the same mistakes 3. Add linting rules and the likes so our CI environment catches any mistakes (where possible)

Is it something you'd consider? Even if it's not a performance bottleneck right now it's probably worth it to reduce server costs (more efficient Ruby implementation = fewer servers required to run GitLab.com). Could be looking at serious gains, 3x over CRuby looks to be a fairly reasonable goal when using RubyTruffle (slow startup times can be mitigated against with SubstrateVM), and if that's not an option due to it being a fairly new project, it seems like JRuby could give a decent performance boost too. https://pragtob.wordpress.com/2015/11/30/benchmarking-a-go-ai-in-ruby-cruby-vs-rubinius-vs-jruby-vs-trufflegraal/ https://pragtob.wordpress.com/2015/11/30/benchmarking-a-go-a... https://m.youtube.com/watch?v=wwEVakQzVAw https://m.youtube.com/watch?v=wwEVakQzVAw

connorshea 10y ago
JRuby isn't an option for us because we use too many gems, many of which have compatibility issues with JRuby's implementation of Ruby. This is especially a problem for gems with C extensions. I think Truffle is the most interesting new development in this realm, if it gets support for C extensions as they plan for it to, it may eventually be reasonable to run GitLab on it. That wouldn't be for a few more years though.
YorickPeterse 10y ago
There is no such thing as: 1. Replace Ruby implementation 2. ??? 3. Everything is 3x faster Whatever an implementation or product claims, it's just not possible. While we could benefit from not having a GIL (something Truffle has if I'm not mistaken), it's not a free trade-off. For example: * JRuby typically requires quite a bit more memory compared to CRuby, the same probably applies to Truffle * Dependencies might have to be replaced if they're written in C. I personally don't buy Truffle being able to support all extensions. It's super fucking hard. I spent a few years working on Rubinius and had the unfortunate experience of having to deal with C extensions a lot. Supporting these properly is really, really difficult. * JRuby might not work on all platforms we support. For example, we support Raspberry Pi's and the likes and it's not clear if JRuby would work there Most importantly of all: a large portion of our slowness is due to badly written SQL queries, code that hammers the database way too often, and our Git operations. None of this would be solved by switching to a different Ruby implementation. The only way to solve this is to: 1. Solve the code 2. Educate developers so they don't make the same mistakes 3. Add linting rules and the likes so our CI environment catches any mistakes (where possible)