Most developers have pretty short attention spans and we expect things to be fast. In development on a large-ish Rails application due to the way Rails autoload

Most developers have pretty short attention spans and we expect things to be fast. In development on a large-ish Rails application due to the way Rails autoloading works (I heard this is changing soon?) just editing certain files is not that far off from a full-restart. So the "F5 Driven Development" flow is very slow on our app. The Rails app I work on is 9 years old (no rewrites, go us!). 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. 0 - https://gist.github.com/josevalim/470808 https://gist.github.com/josevalim/470808 1 - https://github.com/tmm1/test-queue https://github.com/tmm1/test-queue