Performance of Ruby is often terrible. At some point GitLab will have to recognize that. I know they have some Go in the stack, but so much is of the application is hinged on the Ruby monolith.
Performance is one thing, the hill a contributor must climb is another; I've taken a swing or two at trying to fix some of the 43,000 issues and in my opinion if RubyMine has no idea what's going on with your codebase, maybe you have a problem
Almost all of Rails codebases that I worked on, had performance problems (in that it was hurting the bottom line). But most often, the solution was found elsewhere: tune the database, use AR smarter, spin up more servers, buy a bigger database server, etc.
I don't know much about GitLab's code, but in my experience, language execution speed is one of the very last things you look for when optimizing the performance of a web application. The odds are overwhelmingly higher that the problem exists at the database, redis, API interaction, e-mailing, or 1,000 other things before rewriting in a faster language would be advantageous. Even then, it's often more cost effective to throw more servers at the problem. Web and worker servers typically scale horizontally effectively.
8 comments
[ 2.5 ms ] story [ 29.6 ms ] threadWhether they have to act on it? Maybe not.
Almost all of Rails codebases that I worked on, had performance problems (in that it was hurting the bottom line). But most often, the solution was found elsewhere: tune the database, use AR smarter, spin up more servers, buy a bigger database server, etc.
2. I didn't ignore the whole article, the article ignored my concern save for a few sentences.