Tag: Performance

Mongoid (MongoDB) has_many/belongs_to relation and wrong index being picked

January 15, 2015 /

Sometimes when you have a belongs_to relations, you may notice, that getting an owner object can be really slow. Even if you add index like this:

class Activity
  include Mongoid::Document
  include Mongoid::Timestamps
  include Mongoid::Attributes::Dynamic
 
  belongs_to :person

  index({ person_id: 1 }, background: true)
end

Mongoid might not catch it. Unfortunately you can't just explain it, since this relation is returning an object not a Mongoid::Criteria. Luckily you can just hook up to your slow-log and grep for it (or you can just benchmark it). Either way, if you notice that it's not using index as it should, first declare it the way it should be declared:

class Activity
  include Mongoid::Document
  include Mongoid::Timestamps
  include Mongoid::Attributes::Dynamic
 
  belongs_to :person, index: true
end

If you already had an index on a person_id, you don't need to recreate it. It should use it out of the box. If it doesn't help, you can always use explain to overwrite the default finder method for this relation:

class Activity
  include Mongoid::Document
  include Mongoid::Timestamps
  include Mongoid::Attributes::Dynamic
 
  belongs_to :person, index: true

  def person
    # Here in explain you need to provide index name
    @person ||= Person.hint('person_id_1').find_by(person_id: person_id)
  end
end

Note: this post might be somehow related to this issue.

ActiveRecord count vs length vs size and what will happen if you use it the way you shouldn’t

September 15, 2014 /

One of the most common and most deadly errors you can make: using length instead of count. You can repeat this multiple times, but you will always find someone who'll use it the way it shouldn't be used.

So, first just to make it clear:

#count - collection.count

  • Counts number of elements using SQL query (SELECT COUNT(*) FROM...)
  • #count result is not stored internally during object life cycle, which means, that each time we invoke this method, SQL query is performed again
  • count is really fast comparing to length
2.1.2 :048 > collection = User.all; nil
 => nil
2.1.2 :049 > collection.count
   (0.7ms)  SELECT COUNT(*) FROM `users`
 => 16053
2.1.2 :050 > collection.count
 => 16053

#length - collection.length

  • Returns length of a collecion without performing additional queries... as long as collection is loaded
  • When we have lazy loaded collection, length will load whole colletion into memory and then will return length of it
  • Might use all of your memory when used in a bad way
  • Really fast when having a eagerly loaded collection
2.1.2 :055 > collection = User.all; nil
 => nil
2.1.2 :056 > collection.length
  User Load (122.9ms)  SELECT `users`.* FROM `users`
 => 16053
2.1.2 :057 > collection = User.all; nil
 => nil
2.1.2 :058 > collection.to_a; nil
  User Load (140.9ms)  SELECT `users`.* FROM `users`
 => nil
2.1.2 :059 > collection.length
 => 16053
2.1.2 :060 > collection.length
 => 16053

#size - collection.size

  • Combines abilities of both previous methods;
  • If collection is loaded, will count it's elements (no additional query)
  • If collection is not loaded, will perform additional query
2.1.2 :034 > collection = User.all; nil
 => nil 
2.1.2 :035 > collection.count
   (0.3ms)  SELECT COUNT(*) FROM `users`
 => 16053 
2.1.2 :036 > collection.count
   (0.3ms)  SELECT COUNT(*) FROM `users`
 => 16053 
2.1.2 :037 > collection.size
   (0.2ms)  SELECT COUNT(*) FROM `users`
 => 16053 
2.1.2 :038 > collection.to_a; nil
  User Load (64.2ms)  SELECT `users`.* FROM `users`
 => nil 
2.1.2 :039 > collection.size
 => 16053

Why would you even care?

Well it might have a huge impact on your apps performance (and resource consumption). In general if you don't want to care at all and you want to delegate this responsibility to someone else, use #size. If you want to care, then play with it and understand how it works, otherwise you might end up doing something like this:

print "We have #{User.all.length} users!"

And this is the performance difference on my computer (with only 16k users):

       user     system      total        real
count     0.010000   0.000000   0.010000 (  0.002989)
length    0.730000   0.060000   0.790000 (  0.846671)

Nearly 1 second to perform such simple task. And this could have a serious impact on your web app! Keep that in mind.

Copyright © 2026 Closer to Code

Theme by Anders Noren — Up ↑