Hacker News Reader

Comment by Corrado | Hacker News Reader

I've really noticed quite a bit of speed improvement lately with Ruby 1.9.3 and now Rails 3.2.0-rc1, at least in my development environment. It's a good thing too because lately I have been thinking back fondly of the good old Rails 2.x days when you could restart the development environment without flinching. With the latest incarnation of these two tools I love the Rake command again. :)

Now, if we could just get someone to commit the fix for the debugger under Ruby 1.9.3. Not being able to debug, or at least having to work too hard at it, is really a drag on my productivity and is keeping me from moving to the newer faster stuff everywhere. Come on Mr. Moseley, release ruby-debug-base19 v0.11.26 already!

View on HN

does this fix the abominably slow development with the asset pipeline (without the gems needed to hack it and speed it up)?

Basically, can someone give me a way back into pre-3.1 asset pipeline slowdown ?

Can you be more specific? Are you talking about rails startup time or SASS compilation? Or something else?

in dev mode, the asset pipeline induces extremely slow page loads in development (2-4 seconds per page locally)

This has been the single biggest complaint against Rails 3.1 if you google for it. For e.g. take a look at http://stackoverflow.com/questions/8084006/serve-assets-dire...

Similar questions have been addressed by either installing rails-dev-tweaks or by pre-compiling assets - which is then a problem if you're actually working on the UI/JS - which is where half the dev time is usually spent.

Ah, I was wondering how come my development environment had slowed down so much in the past couple of releases. Had I known enough to check for it I probably would have found out about that rails-dev-tweaks Gem sooner.

Anyway, yes I think that this release fixes those issues. However, there appears to be a problem with the SASS @import command and partials[1] so I haven't been able to fully test my system yet with all it's assets working properly.

[1] https://github.com/rails/rails/issues/4041

Sure; no, I've seen the same kinds of problems.

If you are interested, I posted in the comments to this gist (https://gist.github.com/1184843#gistcomment-65875) some changes that we made to our SASS files to markedly increase the compile time.

For us it went from (depending on the machine) something like 40s down to a <5 seconds which was a massive improvement (CSS development was almost impossible for a while there).

I've noticed that using Passenger Standalone is faster than webrick / mongrel in dev mode using Asset Pipeline. Give it a shot.

I just switched to pow to avoid the annoying content-length warnings in 1.9.3 webrick, and it's pretty darn zippy, debug-mode asset pipeline and all:

curl get.pow.cx | VERSION=0.4.0-pre sh

There have been several issues with Sass (sass-rails) and the Asset Pipeline. Some of them involving Compass (https://github.com/chriseppstein/compass/issues/516#issuecom...), some of them due to Sprockets (https://github.com/sstephenson/sprockets/pull/268#issuecomme...).

They have indeed been crippling for front-end development, and majorly under-reported since this summer. So if you're facing any of these issues, please participate in the GitHub Issues threads I linked above and help the relevant teams diagnose/improve the problems.

I found it was really slow when assets were in debug. I generated a new rails app and copied the config from there and then merged in the settings from the old project I needed and it was super fast.

I can only hope that running my app in dev mode in 3.2 won't bleed memory 40 MB per request. I have no such issues in production environment and it makes testing/debugging a royal pain.

It's probably not Rails itself...

I had a similar issue, which turned out to be a bad Rails plugin, which maintained a few unnecessary pointers to my model classes. The small plugin caused a 20+MB per request leak in development. I rewrote the piece of functionality I needed from the offending module & the issue went away entirely.

Sadly, there isn't really decent memory profiler support to help you track it down. I found the issue by running `git bisect run` with a little script which restarted the server, beat on it a bit with `ab` and then printed memory usage with `ps`. Took me about 10 minutes to track it down to the exact offending commit.

How did you deal with the migrations problem? I usually can't bisect Rails code because there's no way to migrate from here to there anymore, let alone do so automatically..

I store the schema as SQL instead of the .rb file nightmare. Here's the script to do it quickly with Postgres & bypass the Rake slowness:

    #!/bin/bash

    root="/path/to/your/code"
    user='postgres'
    db='dev'
    schema="$root/db/schema.sql"

    pg_dump -U $user $db \
      --schema=public \
      --schema-only \
      --no-owner \
      --no-privileges \
      --file $schema

    pg_dump -U $user $db \
      --table public.schema_migrations \
      --no-owner \
      --data-only \
      --insert \
      >> $schema

Then a trivial `dropdb`, `createdb`, `psql < db/schema.sql`

And then a small script with 4 or 5 curl calls can get enough data into the database to drive some tests.

Gah, of course. Brilliant, especially skipping rake. (Though, pro tip: With Ruby 1.9.3, set export RUBY_GC_MALLOC_LIMIT=59000000 and you'll save 5-6 seconds at launch.)

I used this command to get the debugger working on 1.9.3-p0.

    bash < <(curl -L https://raw.github.com/gist/1333785)

Reply on news.ycombinator.com