Ruby's performance does matter. In 2016 you can't call yourself a language optimized for developer happiness when it takes seconds or minutes (in the case of some Rails apps - Hello routes.rb!) just to start up.
I ask because in mine I start up the application very rarely, say when changing a gem, initialization or configuration file. All other times my changes, in development, are automatically refreshed. Hence I rarely start and stop my development system. Of course I am running my development locally. If you were actually deploying your ENV out to some servers continuously for every change then that would be annoying, yet how much of that delay is do to Rails restarting vs doing a remote deploy....
We've tried to use pre-forking preloaders like Spring but we found ourselves force killing Spring more often than it was useful for us.
EDIT: Performance is complicated and can be a sensitive topic so I'm going to elaborate. While dev restart/refresh times are annoying, the real elephant in the room are Rails test suites. We (and many other places I've worked at) rightfully use our test suite as a signal of when to merge and when to deploy. This means the entire suite (~4000 tests - it's a big app!) needs to come back as passing before we will merge a branch that can be deployed. Our current test suite takes about 40 minutes to run in a single process (more on this later) if the planets align.
Here's a list of a few things I've done in my career (I'm very grateful Ruby and Rails have given me a career, btw) to get around Ruby and Rails' performance gotchas:
- Caching logic so complicated that you would think our business domain is actually caching and not our real business.
- Converted a test suite from TestUnit to RSpec (it was fashionable) and then finally back to MiniTest.
- Stopped writing the type of test that is by far the most valuable (End-to-end browser specs) for all but the most important features due to how slow these types of tests are and the amount of false negatives they produce.
- Tried the whole shared_connection.rb[0] trick to share a DB connection between feature spec thread and Rails server threads for transactions in feature specs. It's buggy and made our test suite worse off.
- I've gone back and forth between PhantomJS and capybara-webkit more times than is healthy.
- Wrote code to spoof the User session in the above tests so we didn't have to browse to login_path all the time.
- Set DEBUG_ASSETS to false in development (except for when we're editing CoffeeScript files) to reduce the amount of work that sprockets need to do.
- Used our hosted CI's parallel test runner to try and run things faster. Marginal improvement, proprietary, and lots of yucky config files.
- Used Aman Gupta's test-queue[0] to parallelize our test suite under our own control and now we're looking for automate spinning up instances with 8+ CPUs to hopefully get our test suite to run in less than 5 minutes.
Say what?
http://www.techspot.com/article/1039-ten-years-intel-cpu-com...
You'll notice this does not pick models with far higher core counts. The per-core performance growth may have slowed, but it certainly hasn't stopped.
> Ruby's performance does matter. In 2016 you can't call yourself a language optimized for developer happiness when it takes seconds or minutes (in the case of some Rails apps - Hello routes.rb!) just to start up.
Don't blame Ruby for the complexity of Rails (to be fair, it's not just Rails - a large part of the problem is bundler which happily piles stuff in the load path that causes startup times that grow exponentially with the number of gems)