Jonathan, Ben,
Thanks for the input. Since I''ve read your comments, I made a minor
change and removed the after_initialization code. This resulted in a
bit of a performance increase over the previous version. I''ll be
updating the project page later today.
Here are some benchmark results.
setup: 500 "things", 5000 "widgets" (10 "widgets"
associated with 1 "thing")
user system total
real
find all things 0.083333 0.000000 0.083333
( 0.044024)
find all things (aam) 0.300000 0.016667 0.316667
( 0.192542)
user system total
real
find all things include widgets 1.166667 0.000000 1.166667
( 3.941230)
find all things include widgets (aam) 5.233333 0.000000 5.233333
( 6.412996)
user system total
real
find all widgets 0.216667 0.000000 0.216667
( 0.138359)
find all widgets (aam) 3.183333 0.000000 3.183333
( 1.937386)
user system total
real
find all widgets include thing 0.983333 0.000000 0.983333
( 0.620862)
find all widgets include thing (aam) 4.783333 0.033333 4.816667
( 2.909969)
so there is definitely a performance penalty where finding large
numbers of records and including associations. keep in mind that in
the aam tests, ALL models are aam. In a realworld scenario you may
not need to aam EVERY model.
these are the test results from finding only the first record:
user system total
real
find first thing 0.033333 0.000000 0.033333
( 0.019966)
find first thing (aam) 0.016667 0.000000 0.016667
( 0.005061)
user system total
real
find first thing include widgets 1.616667 0.000000 1.616667
( 4.267549)
find first thing include widgets (aam) 5.416667 0.066667 5.483333
( 6.631500)
user system total
real
find first widget 0.000000 0.000000 0.000000
( 0.000801)
find first widget (aam) 0.000000 0.000000 0.000000
( 0.001166)
user system total
real
find first widget include thing 1.433333 0.000000 1.433333
( 0.973662)
find first widget include thing (aam) 5.100000 0.033333 5.133333
( 3.545063)
again, forgive me if the formatting goes all screwy.
Chris
On 6/21/06, Benjamin Curtis <rails@bencurtis.com>
wrote:> Regarding the performance hit, this patch in the tracker might be
> helpful: http://dev.rubyonrails.org/ticket/5436
>
> Chris, perhaps you''d take a look at including that code in your
plugin?
>
> --
> Benjamin Curtis
> http://www.bencurtis.com/
> http://www.tesly.com/ -- Collaborative test case management
> http://www.agilewebdevelopment.com/ -- Resources for the Rails community
>
>
>
> On Jun 20, 2006, at 8:25 PM, Jonathan Viney wrote:
>
> > Looks good!
> >
> > It is probably also useful to be able to ask if a specific attribute
> > has been modified. Perhaps by appending _modified? to the attribute
> > name. Eg:
> >
> > person.name_modified?
> >
> > Could be equivalent to:
> >
> > person.modified.include?(''name'')
> >
> > Also, you should note that the plugin has quite a large impact on
> > performance because of the use of after_find and after_initialize.
> > http://dev.rubyonrails.org/browser/trunk/activerecord/lib/
> > active_record/callbacks.rb#L154
> >
> > -Jonathan.
> >
> > On 6/21/06, Chris Hall <christopher.k.hall@gmail.com> wrote:
> >> Nothing special, just my first plugin. it came out of a request I
> >> saw on
> >> the list from someone who wanted to be able to tell if a
model''s
> >> attributes
> >> had changed prior to being saved. Well, this plugin does just
> >> that (at
> >> least I hope it does).
> >>
> >> http://rubyforge.org/projects/actsasmodified/
> >>
> >> Please see the README for details. Constructive comments and
> >> criticisms are
> >> appreciated.
> >>
> >> Chris
> >>
> >>
> >> _______________________________________________
> >> Rails mailing list
> >> Rails@lists.rubyonrails.org
> >> http://lists.rubyonrails.org/mailman/listinfo/rails
> >>
> >>
> >>
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>