Hacker News Reader

I have investigated this in detail and the reason for this is really ridiciulous - 80% of this time is spend on executing "require" statements and this is due to really bad design of RubyGems and/or Bundler. They both do their job by augmenting $LOAD_PATH to include all directories containing gem contents. If you then look into how Ruby deals with the $LOAD_PATH, it turns out each time you do a "require" it will go through all of those directories and their subdirectories in search for a file matching what you have required. I used strace to see how this impacts doing "rails console" on an application with around 30 gems - it ended up doing 35000 open calls that ended up with ENOENT. It is beyond my mind how this can remain unfixed for so long. If RubyGems instead maintained a cache from all the gem directories, it could map requires to files without touching the filesystem and it would work many times as fast. Even creating a cache at runtime and then using it for the lookup would be many times as fast. Unfortunately, it is hard to determine a strategy for building this cache that would map the requires to files in exactly the same was as RubyGems, because RubyGems has some pretty weird strategy for determining which files take priority over which files when you do an ambiguous require. Because of this, I haven't yet succeeded in implementing a fix myself and I'm not 100% sure if it is possible. I also tried to contact one of the Bundler guys, but so far haven't had any reply about this.

I started https://github.com/joevandyk/slow-rails to look into this. It's an empty Rails project, except for the Gemfile and one model.

Here's 1.8.7, 1.9.2, and 1.9.3dev running that application's test:

https://img.skitch.com/20110515-x4r8414pkei9j3h73d1sy67iud.j...

1.9.2 and 1.9.3 is really slow at starting up bundler/rails/gems.

Ok so first this is not exactly an empty Rails project. The Gemfile.lock has 221 lines, that amount of dependencies is not normal. To compare the application code for http://www.getharvest.com/ a +5 year old rails project with customers et all and it has 245 gem dependencies (including some that are our own). The +3 year old http://www.coopapp.com has 181 dependencies. Both of these start up within 3-4 seconds on my desktop and due to their age & size they have admitedly too many dependencies. Everytime one is removed I've rejoice.

Please don't call something with 221 dependencies a blank Rails project. More the amount of conflicting half baked gems you've added makes it an unfair complaint about Rails. I've assure you that there is no language / framework in the universe in which does not take a hit when adding too many dependencies. Either execution wise but more often it just breaks your spirit.

Anyway back to numbers, on 3 year old desktop under Linux, executing tests on the "blank" project yielded:

For some reason ruby is much slower on OSX than linux, that is an interesting project to investigate. I've think the platform difference shows the 10 second difference, spite the slower CPU. It would be quite interesting to understand why ruby is slow on OSX. Each to his own itch to scratch.

Why are you equating lines in Gemfile.lock with the number of dependencies?

There are 28 gems specified in the Gemfile. That's not an unreasonable amount of gems. With dependencies, the total amount of gems being required is 76.

Hell, only using Rails and sqlite-ruby will require 26 gems to be installed.

Are you sure that the open calls is the reason why 'require' is so slow?

I have just written a short blog post about this:

http://www.stifflog.com/2011/05/15/why-is-rails-startup-so-s...

I'm not that deeply in Ruby/RubyGems/Bundler internals to be 100% sure, but on the other hand I really can't see how it could work reasonably fast while using the strategy for looking up libraries it uses.

Great work! Yehuda is brilliant, although I'm sure he's busy now and I don't know how much bandwidth he would have to address that. I think he's full bore on Sproutcore.

If I calculate (20 seconds) x (number of times I bootstrap rails), it might even be worth my time to have a go at it.

There is a bug supposed to be fixed in ruby 1.9.3 that addresses something to do with the load path and bootstrap performance, but no idea when that's due to land. If it's truly the cause, it seems like this should be a patch to 1.9.2 instead.

You might also want to see if this is related:

https://github.com/rdp/faster_require/blob/master/lib/faster...

I haven't been using Rails for nearly as long as you have. As a result, I thought the bootstrap time was something Rails developers just "put up with". I would have thought that someone else would have noticed this problem and done something about it...surprisingly I don't think many have.

Django, by comparison, bootstraps the environment almost instantly.

I have also been looking for an answer for how to deal with this issue, so I just started a bounty on your question for 200 reputation. Looking forward to a good answer; it may very well convince to go back to Rails.

You can slow down the startup time for Django if you have lots of installed apps and nested modules but it is still in the order of seconds rather than tens of seconds.

Deleted comment

That's not the dev server, which is able to start and reload pretty fast. That post is complaining about the startup time for loading several pre-forked Python VMs on the first request.

That's pretty much a production problem. It's somewhat common to see "warmup" scripts that make sure all the VMs start.

The OP was talking about development time.

"That's not the dev server, which is able to start and reload pretty fast...That post is complaining about...a production problem."

The issue is actually that it takes time to load the application code and dependencies, something that applies to Django, Rails and just about any similar framework, regardless of whether it's the production or development environment. In general, the production environment will actually be faster at this.

Just to clarify the context to future readers, I deleted by post because I wasn't interested in discussing django, but since you responded I'm addressing it. My original post pointed out that in my experience it indeed does take time to load django and linked to this post: http://stackoverflow.com/questions/1702562/speeding-up-the-f...

Yeah, I tried Django 2 years ago and sort of wish I had stuck with it primarily for this reason. (Additionally I much prefer the Python "no magic" philosophy, although I've gotten used to tracing through Ruby craziness.)

The Rails community (at least at the time) was so much larger and more open that it seemed like a better bet. Rails 3 was coming up and I knew Yehuda was doing brilliant things with the Rails 3.0 architecture. Plus, Moore's law right? - not helping!

I'd love for some hard core Rails guys to get in here and offer some real solutions! As much as I have issues with some things about Rails, it is largely a great tool for me, and I know it so well I'd like to be able to continue using it without tearing my hair out every time I need to run a simple test.

Sadly this days most Python frameworks (including django) are quite full of all kinds of dark magic.

If you want a blissfully magic-free language try Go ( http://golang.org ).

I dunno, I've been at this for 6 years with Rails, am running a 4 year old mbp that dogs it with Java stuff but hangs in ust fine with Ruby. Maybe my apps aren't nearly as huge as the ones you're loading, but I've done some large ones.

But I share your frustrations re: "metawhare" :) Solution is just to hang around with responsible devs.

"Starting a test or server on my dev machine takes 20-30 seconds. Particularly with tests, this is a huge problem for doing proper TDD"

Long startup times or not, sounds like you should probably be using autotest or watchr. 20-30 seconds is not normal. Unless the app has a very large amount of code and dependencies, that sounds like an environment issue.

"while most "Rubyists" would rather pollute the namespace"

That's unfair, and I say that as someone who is very adamant about clarity, explicitness and simplicity in my apps. In my experience, most (not all, but most) of the libraries where people are doing weird things are libraries that are far from necessary, so avoiding that is trivial.

For instance, you cite metawhere. First, I haven't investigated the implementation in depth, but, FYI, it doesn't appear to use method_missing at all. Secondly, I'd be very hesitant to include a library like this in an app, regardless of the implementation, since it's too invasive of a dependency.

autotest or watchr doesn't help startup times -- I'm not sure why you mentioned that here.

I don't think the performance problems are affecting ALL applications - some people don't see any problems. I do think there is something wrong in Ruby or Rails that doesn't happen in all code paths.

"autotest or watchr doesn't help startup times -- I'm not sure why you mentioned that here."

If you use autotest or watchr you aren't starting up the environment very frequently.

I'm not sure why you think that. Unless you use spork or something that preloads the rails environment then forks it on every test run, autotest/watchr will boot the whole rails environment from scratch on each run.

You're right. I'm distracted by the reported 20-30 second environment load time for each test when it only takes about 7 seconds for my tests to start with autotest in my current pretty large app on an older MBP.

Autotest doesn't help startup times, but it can help mitigate the problem somewhat since the tests will start almost instantly when you change a file, saving a few seconds.

It's a good suggestion, but doesn't solve the problem.

"Long startup times or not, sounds like you should probably be using autotest or watchr. 20-30 seconds is not normal. Unless the app has a massive amount of code and dependencies, that sounds like an environment issue."

Autotest helps some, but 20-30 seconds is pretty standard fare. Maybe I use too many gems, but I don't think I should forgo reusing community code to reduce start times.

Maybe it's unfair to make a generalization about "rubyists," but it seems people in the community get overly excited about something that saves 5 characters in their codebase or makes something readable to non-devs (for all those non-devs who will read your code.

Another example - the ubiquity of DelayedJob. The standard usage is to insert delay into your call chain, so foo.delay.send_emails instead of foo.send_emails. This pollutes the ENTIRE object space with the method delay, in addition to the fact that it doesn't work well on many objects. I complained about this practice and the response was that it was clearly better to write foo.delay.send_emails instead of Delayed.add_job(foo, :send_emails) or something. For me, I find any pollution of namespace where conflict is possible highly questionable, although sometimes it's ok.

Metawhere adds methods like .eq and .lt to Symbol (symbol is something like an intern string, e.g. :foo or 'foo in Python).

Polluting the namespace like metawhere does is a significant problem.

We use datamapper on our app, and were looking at doing some of our analytics on mongo at one point, but since both mongomapper and datamapper both define 'helper' methods on Symbols, they can't both be in use at the same time.

If we _really_ wanted to use mongo it would need to be from a completely separate codebase either talking to the db via Sequel or something, or talk to our main app via REST calls - neither being a particularly pleasant solution.

"I don't think I should forgo reusing community code to reduce start times."

Using too many gems is an problem for a lot of reasons, though. You are introducing dependencies that you then need to manage and update, they often do more than you need to while being harder to maintain (you might end up with a bunch of forks in your gemfile as things get outdated), they are sometimes invasive and will require big rewrites to switch from.

"it seems people in the community get overly excited about something that saves 5 characters"

I agree (though I'd modify to to say "some people in the community"), I just find that I don't encounter it much when I'm following best practices myself.

True that gems often do more than I need, but should I? 1) Write my own authentication code 2) Write my own ical feed code (just added this in about 2 hours using ri_cal, which has way more features than I need) 3) Write my own code to inline css in email 4) Write my own Facebook API library 5) Write my own admin interface 6) Write my own SCSS and HAML processors 7) Write my own file attachment and processing code 8) Write my own background processing library 9) Write my own CSS/JS compression library

You get the point.

I use gems that save me tons of time. If not for gems, I would not be using Rails.

That's only 9 libraries, and that shouldn't be enough to cause your load times to reach 20-30 seconds.

Also, since you asked :-) I would question #5. Auto admin libraries (and this applies to multiple languages and frameworks) are generally heavy, too general and have code hidden away in the library. In contrast, banging out crud views and controllers in a locked-down namespace is easy, only relies on same dependencies as the rest of the app, can be customized for the specific business needs and all the code is in one obvious place.

It would take me many days to create and test an admin with multiple objects, even a simple one, and then I have to maintain it. I install rails_admin and I've got what I need. This is for internal testing and maintenance. I don't care if it's heavy.

I suppose your logic makes sense if you're gainfully employed, but I bang this stuff out for myself and clients. A 90% solution with one line of code sure beats weeks of work.

I've started a sample Rails 3 application here: https://github.com/joevandyk/slow-rails

Other than a fairly standard list of gems in the Gemfile and one Model with two columns, the application is empty.

On my machine with Ruby 1.9.2-p180, it takes 20 seconds to start. And the application is empty!

I was at the BBC working on a large Perl codebase which was a fairly typical Catalyst/DBIx::Class stack. It had thousands of tests which thanks to the foolish way we loaded reference data and pre-populated memcache etc. had the test suite running for 3 hours. As you can imagine, it was a nightmare for TDD and indeed for large merges (by the time you've run tests trunk would have inevitably changed). We never fixed it thanks to a combination of lazyness and a case of "it's legacy code, won't be around much longer" syndrome.

http://qwerly.com runs a tight and fast Node.js stack at the front-end with a test suite that takes less than a second to run (a few hundred assertions). I'll dedicate much time to the framework around it's tests and make sure it's never slow.

> with a test suite that takes less than a second to run

I'm jealous. That would probably save me a huge portion of my development time. Node is my top contender if I dump rails.

I had a similar issue using Django+PostgreSQL on Ubuntu 11. Running the test suite was taking 10s of seconds in that combination which wasn't too bad but hurt my test->fix->test cycle when debugging PostgreSQL related issues (during normal dev I run the test suite in a in memory SQLite database).

Took a little time to work it out as I am new to PostgreSQL but it was worth it to avoid a pause in the problem solving cycle.

Problem and solution explained on my blog: http://www.roryhart.net/code/slow-create-database-with-postg...

One thing I've been investigating is using RabbitMQ to separate the logic out of the monolithic rails application.

Beetle looks promising. http://xing.github.com/beetle/ You can do both RPC and async messaging. (Might want to wait a few days before using it, there's issues with some libraries that it depends on that will be fixed soon).

I don't understand how that helps. This is a problem for pretty simple Rails applications.

Besides, why should I have to set up and learn RabbitMQ to have a decently performing web framework? This is 2011 and this shit is slower than my old Java framework running on an ancient processor in 1995.

I just tested this on one of my apps (yakkstr.com) and 'rails c' and 'rails s' both startup in about 5 seconds. I'm on 1.8.7 and rails 3, not sure if that makes a difference, but 20-30 seconds doesn't mesh with my experience at all.

I'm on a 2.66 GHZ i5 imac, not an SSD.

Would you mind testing out https://github.com/joevandyk/slow-rails and see how long 'rake' takes to run?

For me on 1.8.7, it takes about 7-8 seconds. Annoying because the application is empty, it's just 28 gems being loaded. On 1.9.2, it's 20 seconds or so.

I get the same, I hadn't noticed it because I'm still using 1.8.7

Have you tried spork? https://github.com/timcharper/spork

Also, have you opened a ticket or looked to see if there is one already?

http://redmine.ruby-lang.org/issues/3924

Re: your knock on Cucumber – isn't Cucumber explicitly designed to enable human readability so that non-programmers can collaborate on features in quasi-colloquial English? Can you expand on what you dislike about it?

I'm not trolling; I'm genuinely curious about this.

Another person with a similar problem: http://www.ruby-forum.com/topic/393617

How often do you need to endure that 20-30 second startup time? Is it every time you change anything?

During deploys, running a test, configuration changes, starting anything that loads the whole rails environment.

Pretty much ANYTHING you do. Start a console, start a server, run a test, migrate your database, run a rake task.

It's a huge productivity killer for me. And as other comments have stated, it's surprising this issue is not discussed more.

Not solutions, but workarounds:

Keep console open and use reload! when you change your models, for starting a server I don't have much other than keep it running the background, running a test -- use spork, migrate your db and run rake tasks -- try to take advantage of the fact that you can specify multiple rake tasks at a time; "rake db:migrate db:test:prepare"

More good suggestions. I'd love to get spork working, but rspec syntax makes me cringe and I haven't gotten it to work with test-unit. I found a plugin and a fork, neither of which I could get working.