Every time a pane of the block content type is displayed, hook_block('list') is invoked for all modules. This is an expensive operation.
This patch adds the "content type" hook for the block content type. Now hook_block('list') is only invoked for the relevant module.
See also #779012: Add "content type" hook to mini panels content type.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | block_content_type-1.patch | 3.48 KB | c960657 |
Comments
Comment #1
c960657 commentedComment #2
sdboyer commentedI already committed a patch that statically caches the block data in the content_types callback #754086: Performance: Loading sitewide block list multiple times per page; because of the potentially large overhead involved in invoking the block list so many times, I prefer that approach. Some compelling numbers could change my mind, though :)
Comment #3
c960657 commentedOn my development site, the following takes 2.5 seconds:
By far the most expensive function is views_block(). It exposes each defined view as a block. My site has more 500+ views defined. These are not manually defined views. AFAICT most views are exported by the Nodequeue module in nodequeue_views_default_views(). I don't use any of these views as a block.
My 100+ mini panels are also exposed as blocks. In total, more than 900 blocks are returned by the above code.
With my patch we only invoke hook_block() on modules whose blocks I actually use and not others. This saves me a call to views_block() and the corresponding 500+ calls to panels_default_block_info() for each of the blocks returned by that function. On my development machine, the patch cuts about 2 seconds off the page generation time for pages using the block content type.
Is that compelling enough? :-)
I know that this is a complex site with a lot of modules, views, mini panels etc. But even on a smaller scale there may be a measurable saving, especially with modules like Views that expose a lot of blocks based on other data sources.
Comment #4
sdboyer commentedLOL. Yeah, that counts as compelling :) I really didn't do the math on how that would scale up, and I think I also forgot that we'd be able to avoid iterating over ALL modules' blocks in the targeted callback. Rolled back the other one, and committed this. Thanks for being so on the ball.