slows down any request in development mode

[vitaly]

When having active admin with many models all requests in development mode slow down to a crawl.

It seems like generating routes is the problem. it looks like it loads all the models and is done on each request.

[rdj]

Any work around to this? It kills dev speed.

[j-manu]

Check your memory usage. #170 maybe the problem ? I have a fork which disables the reloading of models in development and that stops the memory leak https://github.com/j-manu/active_admin

But it is only useful when you are not developing active admin models and is doing other development.

[rdj]

Similar to j-manu's fork, I monkey patched around this in my initializer:

+unless ENV['ENABLE_ACTIVE_ADMIN_RELOADS']
+  module ActiveAdmin
+    class Reloader
+      def attach!
+      end
+    end
+  end
+end

[j-manu]

@rdj: Awesome. The monkey patch is much more flexible.

[vitaly]

This doesn't work with the latest version of active admin.

[aaronjensen]

The issue appears to be the fact that it regenerates stylesheets every request. This seems to fix it (at the end of development.rb)

module ActiveAdmin
  class Application
    private
    def generate_stylesheets
    end
  end
end

though this probably means you need to check in your active_admin.css and regenerate it manually if you update activeadmin. I can't think of a good reason these should be generated on the fly, it's a gem.

[aaronjensen]

After further digging, the issue is that lib/active_admin/sass/css_loader.rb overwrites the scss extension to be css.scss. This causes sass to be unable to find modification times of scss files. If you're using any scss files, it will assume that they've been changed because it can't find them.

Ah, the dangers of monkey patching.

[aaronjensen]

Another fix that doesn't require monkey patching:

Sass::Plugin.options[:always_check] = false

That will speed up the all but the initial load. It will still generate sass initially. If you are running and trust guard completely you can try this:

Sass::Plugin.options[:never_update] = true

That will speed up the initial load as well. All of these go in your development.rb.

[j-manu]

Great!!

Does this eliminate the memory leak?

[aaronjensen]

I haven't experienced the leak (though I haven't been paying attention), but it's unlikely. If it did then there would be a leak in sass. The fix proposed in that thread is probably the best bet.

[MrJoy]

The memory leak is unrelated, but the source of the leak is also a source of per-request performance problems. I've suggested fixes in the thread on ticket #170.

[zacksiri]

I tried adding that line Sass::Plugin.options[:never_update] = true to the end of development.rb and i am getting this error

uninitialized constant Sass::Plugin (NameError)

using rails 3.1

[aaronjensen]

I don't know if this problem exists in Rails 3.1, I'm pretty sure Sass and active_admin both do something completely different for 3.1, but you'd have to do some digging.

[garethbradley]

I am using 3.1 and all page requests whilst the active_admin gem is referenced in the Gemfile are slow (up to 13 seconds or so, but usually around 8s).

[alikapadia]

same here, using 3.1 as well.

also getting: uninitialized constant Sass::Plugin (NameError)
when I use Sass::Plugin.options[:never_update] = true

[robeastham]

Same here, tis really slow and I think AA is the only thing that changed. Prior to that my app was zipping along with Rails 3.1 and the asset pipeline config I had going. ;(

[marbemac]

Same issue here, major slow down as soon as I enable active admin in my 3.1 apps.

[pixelmultiplo]

+1
and the documentation is really lacking too

[andreslucena]

+1

Same issue here. Rails 3.1
There's quite a difference between having ActiveAdmin installed or not in development.

[pixelmultiplo]

To solve the: uninitialized constant Sass::Plugin (NameError), i put a sass.rb in the initializers folder. The solutions, however, does not work in Rails 3.1, still so slow it's impossible to develop.

[jaybrueder]

Same issue here. It all goes really really slow. I am on Rails 3.1

[l4u]

+1

[davidkariuki]

Same here on rails 3.0.10. It's running pretty slow even with

Sass::Plugin.options[:always_check] = false
Sass::Plugin.options[:never_update] = true

in development.rb. I assume it's due to the memory leak.

[brendanstennett]

+1
Just commenting out the line ActiveAdmin.routes(self) offers a dramatic speed improvement on the rest of the app.

[clarif]

To solve the uninitialized constant Sass::Plugin (NameError) issue in the development.rb file, just put the options in a after_initialize block. e.g.:

  config.after_initialize do
    Sass::Plugin.options[:always_check] = false
    Sass::Plugin.options[:never_update] = true  
  end

[marbemac]

Any updates on this one? Makes development quite painful.

[crosebrugh]

I did a bit of profiling and found that neither application.rb:generate_stylesheets nor the router.rb:apply take much time. The problem seems to be due to the assets (including images).

This gem - https://github.com/wavii/rails-dev-tweaks - is a savior. The default config seems to cover the performance issues mentioned here.

[marbemac]

@tlatim awesome - works like a charm!

[dgutov]

Anything that would help with Rails 3.0?

[arbarlow]

subscribing..

[espen]

@arbarlow tip: there is a link on the bottom of the page for subscribing to notifications without commenting.

[tomblomfield-zz]

Huge problem here as well. Pages in our development environment are taking 20+ seconds to load...

[daliborfilus]

Hi. I'm on Rails 3.1.1, Ruby 1.9.2 (with require patch) and this is TERRIBLE.
Homepage loads in 5 seconds (dev.log lies to me that it was only 500ms :/ pheh).
E.g. I have page where are like 16 images which are loaded through my file-router (disk usage balancer) which uses sendfile and every image takes like 2 seconds, although log says it is 30ms/req.

And I have only 5 models managed by ActiveAdmin.

I've tried:

  config.after_initialize do
    Sass::Plugin.options[:always_check] = false
    Sass::Plugin.options[:never_update] = true  
  end

helped only a little

module ActiveAdmin
  class Application
    private
    def generate_stylesheets
    end
  end
end

helped only a little too

Those are like 30-100ms savings, but where are those seconds?

Gem 'rails-dev-tweaks' helped a little too, but it is still very slow. (I was using rails-dev-boost and both these helps only a little in case of AM).

What REALLY helps is to use that monkey patch:

module ActiveAdmin
  class Reloader
    def attach!
    end
  end
end

everything is lightning fast again.

BTW:
if you put any code to controller {} block within ActiveAdmin.register,
IT WILL EVALUATE FOR EVERY REQUEST (including images, styles, everything).
(At least in development mode, didn't check the production, but I assume it will be the same).

• is there any need to evaluate every admin config on every request which don't belong to admin pages?
  I wonder if controller action is evaluated like this, what about all the scopes, filters, forms? ...
  Its basically rebuilding whole admin structure for every request which shouldn't be necessary...
• why is there any need to use "ActiveAdmin.routes(self)" in routes.rb ... since this is Engine-like app that can add routes dynamically without touching routes.rb? (I've used this in my own "universal-admin" solution)

I will be glad to help. I really like the look and feel of the generated interface... and it's easy to use. (My "hexcmsadmin" is based on the same principle, but it don't have that DSL, I'm basically using just old plain inheritance and I must define the routes myself, but the output is much alike).

Can I help with something to solve this?

BTW2: is there a way to unload devise completely? Since ActiveAdmin have gem dependency to devise I'm lost?

[rdj]

@noice re: devise - see #542

[j-manu]

#466 Has anyone tried this code?

[daliborfilus]

@rdj thanks... but I can see that it is not solved yet.

btw3:
while using that "override-attach!" monkey patch I came into strange errors, when item.kind_of?(Cms::Menu) returns false for item that clearly is Cms::Menu... (doublechecked that via #{item.class.name}; this is raised in a helper called from active admin register block) ... But that happen because of Cms::Menu model is reloaded for that helper but not for ActiveModule...

Anyway, using combination of rails-dev-boost, rails-dev-tweaks and override-generate_stylesheets monkey patch returns speed to a good level. Still a problem though.

[robdiciuccio]

Subscribing. Extremely slow asset load times running Rails 3.1.1 and ActiveAdmin 0.3.2 (master).

[mattvague]

I believe this commit fixes this :-)

c2103ad#commitcomment-683172

[daliborfilus]

I can't really test this as I removed ActiveAdmin from my project and instead did the same functionality in my gem, but it seems promising.

It seems also that it doesn't solve the second (and in fact third) problem and that is the routes generation...
I think ActiveAdmin should just not use any lines in routes, instead define global match routes like
get '/admin/:controller/:action' etc. and catch these,
because just that single line in routes.rb can degrade dev performance greatly due to required load of all models included in admin sections.. and this happens for assets too (as rails needs to load routes file for every request).
I didn't look at the source though so if AA.routes_for(..) already doesn this then ignore this.

Also declaration of the admin menu etc. should get hit just when you hit whatever under /admin, not for all requests.

[dgutov]

Yep, the speedup from c2103ad is huge.

[gabehesse]

+1 for that fix, it cleared up the issue completely over here on rails 3.1.0

[mattvague]

Can I close this?

[robdiciuccio]

Asset load time issue appears to be resolved here on rails 3.1.1

[rdj]

Concur. No longer need my monkey patch using activeadmin-0.3.3, rails-3.1.1, ruby-1.9.3-p0

[davidkariuki]

For me this stops reloading even after I generate new resources or make changes to /admin pages. On rails 3.0.10

[dgutov]

You're not alone, see #707.

[idrozd]

Maybe someone will find it useful:

Disabling rails_footnotes decreased request execution time in AA powered app from 8-13 seconds to about 0,5

[RobWu]

For rails_footnotes performance issue, see indirect/rails-footnotes#71