3

I added the bullet gem to advise me of any N+1 queries in dev (Rails 4.0.2) It advised eager loading two parent associations of a model where I'm displaying all its records.

Before eager loading one of these belongs-to associations:

Completed 200 OK in 5252ms (Views: 1.8ms | ActiveRecord: 114.1ms)

After eager loading:

Completed 200 OK in 6741ms (Views: 2.1ms | ActiveRecord: 146.0ms)

Also, with eager loading, the browser hangs after the console says completed and doesn't updated for an age (about 6 seconds). The server production didn't have this freezing issue but still it appears in this case eager loading is bad advice.

Does it make sense that eager loading can be slower? The view does access the (eager loaded) parent record.

Also the bullet gem doesn't display the call stack for some reason.

usha
  • 28,973
  • 5
  • 72
  • 93
rigyt
  • 2,219
  • 3
  • 28
  • 40

1 Answers1

5

Also, with eager loading, the browser hangs after the console says completed and doesn't updated for an age (about 6 seconds).

As I found out today, it is probably Bullet itself causing this. The reason is because it inserts a middleware which has to go through and analyse your queries before the browser can receive the page. So conceivably any change in your queries may influence how fast Bullet does its thing.

By removing Bullet in one of my apps, I got rid of the extra delay on one of my slow pages, and also reduced actual reported rendering time by a full second.

So when you do your comparison, do it with Bullet disabled (either in your configuration or by removing from Gemfile temporarily and running bundle). It's still a valuable tool, but apparently for some apps it might be a good idea to only enable it periodically when you're trying to optimize things.

Inkling
  • 3,544
  • 4
  • 30
  • 44