This project is archived and is in readonly mode.

#5403 ✓resolved
thieso (at gmail)

STI slow, result of ActiveRecord#find_sti_class should be cached!

Reported by thieso (at gmail) | August 18th, 2010 @ 04:07 PM | in 3.0.2

Hi,

after getting perftools.rb running with 1.9.2 and rails3rc i found that a lot of cycles are burned inside find_sti_class (actually compute_type). this is caused by looking up a constant fails to load:

base.rb:1141

        # Build a list of candidates to search for
        candidates = []
        name.scan(/::|$/) { candidates.unshift "#{$`}::#{type_name}" }
        candidates << type_name

class A < ActiveRecord::Base
end

class B < A
end

this will set candidates to ["A::B", "B"], now "A::B" will go though the long codepath of constantize - and it will everytime a B is instantiated from the database as the const A::B will never come into existance and we don't do negative caching.

my suggestion would be to add a class level cache to the find_sti_class method. that will improve performace of largish queries with sti.

i would write a patch myself, but failed to get the AR testsuite pass on my box.

re,
thies

Comments and changes to this ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

People watching this ticket

Attachments

Tags

Referenced by

Pages