Revised my benchmarking script a bit to account for more content in
the page part and to benchmark the existing Page#part method, which I
postulated was slower than just an Array#find but then didn't include
in the test.
http://gist.github.com/138062
37.5576130 Page#part(name) on a large set of parts using Array#any? +
SQL find (existing part method)
14.4872570 Page#part(name) on a large set of parts using SQL find
13.9826950 Page#part(name) on a large set of parts using array find
1.3265300 Page#part(name) on a small set of parts using Array#any? +
SQL find (existing part method)
1.2686400 Page#part(name) on a small set of parts using SQL find
0.0311450 Page#part(name) on a small set of parts using array find
Begin forwarded message:
From: Jason Garber <j...@jasongarber.com>
Date: June 30, 2009 4:19:46 AM EDT
To: radiant@radiantcms.org
Cc: Sean Cribbs <seancri...@gmail.com>
Subject: Re: [Radiant] a question for Page part(name) method
Having just spent a few hours in those methods (upgrading Chronicle
to 0.8.0), I can speak to your question as it relates to 0.8.0.
Page#parts is an ActiveRecord association: it loads all the
PageParts that belong to that page into an array and then just uses
that array from then on unless you do a find or a count, at which
point it goes back to the database to respond to your find/count.
This is important because if you create a new part (through
parts.build or parts_attributes=), it just gets added to that array
and ultimately saved to the database when you save the page. Thus,
if the page and all its parts are not new records, the instantiated
page/parts should match what's in the database and a SQL find should
be faster than an Array find. If there were any new records,
though, they would not be in the database, so your part(name) would
miss them.
Your question raises an interesting point, though: If we're already
doing an any? on the parts, why would the SQL query be any faster
than Array#find? I did a little benchmarking...
http://gist.github.com/138062 (run with -f profile)
SQLite3:
10.3987880 Page#part(name) on a large set of parts using SQL find
6.5138080 Page#part(name) on a small set of parts using SQL find
4.0115610 Page#part(name) on a large set of parts using array find
0.1251080 Page#part(name) on a small set of parts using array find
MySQL (on a slower machine):
32.3944890 Page#part(name) on a large set of parts using SQL find
17.4200660 Page#part(name) on a small set of parts using SQL find
13.0136880 Page#part(name) on a large set of parts using array find
0.5342530 Page#part(name) on a small set of parts using array find
Sean, does what I'm measuring make sense? Any reason we shouldn't
just switch completely to Array#find for the Page#part method?
Jason
On Jun 29, 2009, at 5:04 AM, Quake Wang wrote:
Hi,
I found that the "part(name)" method of Page model generating many
sql query in development env, I'm curious to know why we need to
check
new_record for Page and its parts?
Regards,
Quake
_______________________________________________
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
_______________________________________________
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
