I have a site which implements custom_url_rewrite_inbound(). I noticed this function was being called an obscene amount of times for many requests, when what I expected was for it to be called only once per request.
It turns out that drupal_get_normal_path calls custom_url_rewrite_inbound, and the latter is called with every request to drupal_is_front_page. Frankly, I'm not convinced these calls to drupal_is_front_page need to call drupal_get_normal_path, but the code is there so someone probably had a reason.
At any rate, the attached patch caches the front page path, so calls to drupal_get_normal_path and custom_url_rewrite_inbound only happen the first time drupal_is_front_page is called. With this patch applied, custom_url_rewrite_inbound() is called twice per request. Once when it is actually needed, to rewrite the incoming request. And a second time to rewrite the front page path, which as I said earlier I'm not convinced is actually necessary or good.
| Comment | File | Size | Author |
|---|---|---|---|
| #25 | drupal_is_front_page-D6.patch | 1.04 KB | smk-ka |
| #24 | 6.x-static-cache-drupal_is_front_page-340557-24.patch | 1.15 KB | dropcube |
| #21 | 340557-drupal-is-frontpage-D7.patch | 4.72 KB | dave reid |
| #19 | 340557-drupal-is-frontpage-D7.patch | 4.72 KB | dave reid |
| #15 | 340557-drupal-is-frontpage-D7.patch | 8.18 KB | dave reid |
Comments
Comment #1
dave reidWe use the same static caching with nearly every other function in path.inc, so it makes sense to implement it for drupal_is_front_page() as well. With a base install, 10-node front page, and a site mission statement enabled, drupal_is_front_page() is called 16 times! I did some ab benchmarking (-c 2 -n 500) and it did marginally improve performance:
Before patch (current HEAD):
After patch:
This is a good find and moving this to the 7.x queue so we can fix there first and then back-port since this won't be an API change.
Comment #2
dave reidComment #3
Anonymous (not verified) commentednice catch! simple patch, all tests pass, RTBC.
Comment #4
Dave Cohen commentedThe performance improvement will be even more for sites that implement custom url rewrites. Thanks for pushing this through.
Comment #5
Anonymous (not verified) commented@Dave: in #drupal, webchick asked if its possible to add a test for this?
Comment #6
dave reidHmm, I'll work on it. It might take a little workaround to get it to test.
Comment #7
dries commentedPatch looks good to me but let's wait for a test to emerge (per webchick's request). :)
Comment #8
dave reidTest completed and ready for review.
Comment #9
dave reidMarked #313123: Statically cache drupal_is_front_page() as a duplicate of this issue.
Comment #10
dave reidFixed a commented section that should have been un-commented.
Comment #11
dries commentedSmall request: can we change 'drupal_is_front_page' in
+ drupal_set_message('drupal_is_front_page: ' . (drupal_is_front_page() ? 'TRUE' : 'FALSE'));to just 'front page'?Comment #12
Anonymous (not verified) commentedlooking good, more core code with tests. comments on the new test:
could we have a comment with that?
this looks to be testing variable_(set|get) more than the site frontpage functionality. perhaps it would be better to test this via drupal's interface? i.e., create an admin user,
drupalGet('admin/settings/site-information'), etc?Comment #13
dave reidThanks for the review. This should probably be in system.test and not a path.test then if we're going to test the front page admin. Working on another revision!
Comment #14
dave reidRevised test that's a part of system.test now. It tests the setting the front page at admin/settings/site-information (and also an invalid front page path). I couldn't resist doing a little cleanup on system.test as well, so forgive me. As for #11, I changed it to drupal_set_message(t('On front page.')); because on the default front page with no nodes, the "get started with your install" text has the string "front page" in it.
Comment #15
dave reidHad a line with whitespace in last patch.
Comment #16
dave reidFound a little bug while trying drupalPost-ing to admin/settings/site-information. Please don't commit this until #343765: DrupalWebTestCase does not set required site_mail variable during setUp() is committed. I will provided a revised patch once that is committed.
Comment #17
dave reidNevermind... #343765: DrupalWebTestCase does not set required site_mail variable during setUp() is marked as "won't fix" now.
Comment #18
dave reidAlso note the patch in #15 has passed testing-bot, the results have failed to be posted back here:
http://testing.drupal.org/pifr/file/1/2201
Comment #19
dave reidRevised de-meowed test.
Comment #21
dave reidRevised patch now that #343765: DrupalWebTestCase does not set required site_mail variable during setUp() landed in core.
Comment #22
dries commentedCommitted to CVS HEAD. Thanks!
Comment #24
dropcube commentedCan we port back this to 6.x ? It is a performance improvement, doesn't break any API, and is a simple patch.
Comment #25
smk-ka commentedCleaned patch from added whitespace. Would be nice to see this fixed in D6, too.
Comment #26
dave reidLooks good.
Comment #27
gábor hojtsyCommitted. Not sure when we'll see an issue popping up about being no way to clear this cache out though :P