4 ms·

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

by Corrado 15y ago

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!

ascendant 15y ago
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.
- snprbob86 15y ago
  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.
  - jaylevitt 15y ago
    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..
    - snprbob86 15y ago
      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.
      - jaylevitt 15y ago
        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.)
sandGorgon 15y ago
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 ?
- tmeasday 15y ago
  Can you be more specific? Are you talking about rails startup time or SASS compilation? Or something else?
  - sandGorgon 15y ago
    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-directly-no-asset-pipeline-in-development 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.
    - Corrado 15y ago
      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 https://github.com/rails/rails/issues/4041
    - ruckusing 15y ago
      I've noticed that using Passenger Standalone is faster than webrick / mongrel in dev mode using Asset Pipeline. Give it a shot.
andyl 15y ago
I used this command to get the debugger working on 1.9.3-p0. bash < <(curl -L https://raw.github.com/gist/1333785)

by Corrado 15y ago

ascendant 15y ago

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.

snprbob86 15y ago
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.
- jaylevitt 15y ago
  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..
  - snprbob86 15y ago
    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.
    - jaylevitt 15y ago
      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.)

sandGorgon 15y ago

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 ?

tmeasday 15y ago
Can you be more specific? Are you talking about rails startup time or SASS compilation? Or something else?
- sandGorgon 15y ago
  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-directly-no-asset-pipeline-in-development 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.
  - Corrado 15y ago
    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 https://github.com/rails/rails/issues/4041
  - ruckusing 15y ago
    I've noticed that using Passenger Standalone is faster than webrick / mongrel in dev mode using Asset Pipeline. Give it a shot.

andyl 15y ago

I used this command to get the debugger working on 1.9.3-p0. bash < <(curl -L https://raw.github.com/gist/1333785)