4 ms·

While DHH says that CPUs in 2004 were fast enough to run Ruby, while CPUs have relatively stayed the same speed the call stack and complexity of Rails has proba

While DHH says that CPUs in 2004 were fast enough to run Ruby, while CPUs have relatively stayed the same speed the call stack and complexity of Rails has probably doubled or triple in that time period. 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.

DamnYuppie 10y ago
Help me understand how, in your workflow with Ruby on Rails, a few second delay in staring up the application hampers developer happiness? 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....
- rubiquity 10y ago
  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
  - deleted 10y ago
    [deleted]
- microcolonel 10y ago
  Rebuild times for almost any decent C codebase are less than that, and people should complain. Wait a bit longer, lose more feedback cycles.
  - DamnYuppie 10y ago
    When I used to do C++ the build time was quite long, of course this was in 2005 using lots of STL, so that is not really a fair comparison. As such do you have any open source examples of decent C codebases? I would actually like to try this out for giggles.
- mnutt 10y ago
  Running specs/tests involves reloading the environment for most people. Spring is surprisingly good for this, but you can still run into weirdness where spring needs to be reloaded due to some sort of state issue.
  - spinlock 10y ago
    exactly. Rspec/rails is my favorite vim plugin but I really hate the time I spend waiting for the spec to run after I've typed \s (note: that's the actual key sequence not an indication that I'm being sarcastic).
vidarh 10y ago
> while CPUs have relatively stayed the same speed Say what? http://www.techspot.com/article/1039-ten-years-intel-cpu-compared/ 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)
- rubiquity 10y ago
  The increase in per-core performance has still less than doubled in that time span.
  - vidarh 10y ago
    That's not what the article I linked to says, unless you limit what you consider to very specific workloads.

DamnYuppie 10y ago

Help me understand how, in your workflow with Ruby on Rails, a few second delay in staring up the application hampers developer happiness? 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....

rubiquity 10y ago
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
- deleted 10y ago
  [deleted]
microcolonel 10y ago
Rebuild times for almost any decent C codebase are less than that, and people should complain. Wait a bit longer, lose more feedback cycles.
- DamnYuppie 10y ago
  When I used to do C++ the build time was quite long, of course this was in 2005 using lots of STL, so that is not really a fair comparison. As such do you have any open source examples of decent C codebases? I would actually like to try this out for giggles.
mnutt 10y ago
Running specs/tests involves reloading the environment for most people. Spring is surprisingly good for this, but you can still run into weirdness where spring needs to be reloaded due to some sort of state issue.
- spinlock 10y ago
  exactly. Rspec/rails is my favorite vim plugin but I really hate the time I spend waiting for the spec to run after I've typed \s (note: that's the actual key sequence not an indication that I'm being sarcastic).

vidarh 10y ago

> while CPUs have relatively stayed the same speed Say what? http://www.techspot.com/article/1039-ten-years-intel-cpu-compared/ 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)

rubiquity 10y ago
The increase in per-core performance has still less than doubled in that time span.
- vidarh 10y ago
  That's not what the article I linked to says, unless you limit what you consider to very specific workloads.