Re: [development] RFC: info hook standardization
I just think it wold be cool to support both options, as some items may be user specific. I'm not excluding normal cache_set/cache_get. I'm still think in terms of a more general cacheable module_invoke_all and not specifically hook_*_info. -----Original Message----- From: Larry Garfield <larry@garfieldtech.com> Sent: May 19, 2008 8:31 PM To: development@drupal.org Subject: Re: [development] RFC: info hook standardization On Monday 19 May 2008, Darrel O'Pry wrote:
Ah, indeed! Make that 2 more attributes of an info hook:
- It has a commonly-named rebuild function: drupal_rebuild_$singularNoun() (or something). - drupal_rebuild_$singularNoun() is called as part of the master cache reset function.
--Larry Garfield
but this wouldn't be able to reset a static cache variable? would it? unless we had something like. I really like to two stage cache for things that might possibly only want to be cached per request...
function module_invoke_all_cached() { static $cache = array();
$args = func_get_args(); $hook = $args[0]; unset($args[0]); if (!is_string($hook)) { $cache = array(); } }
I think you're misunderstanding what I mean by cached. For an info hook, I mean cached to the database (either cache_set() or something like {menu_router}) so that it never gets called again except in unusual circumstances. A static cache only lasts for the duration of the request, and is not what I mean by caching here. Think hook_menu(), not hook_forms(). -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Monday 19 May 2008, Darrel O'Pry wrote:
I just think it wold be cool to support both options, as some items may be user specific. I'm not excluding normal cache_set/cache_get. I'm still think in terms of a more general cacheable module_invoke_all and not specifically hook_*_info.
There may be an advantage to that, but that's separate from what I'm proposing. :-) It sounds like most people are in favor of something like this, though. Is anyone opposed to some written standards that we can then apply to code? -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Mon, May 19, 2008 at 11:18 PM, Larry Garfield <larry@garfieldtech.com> wrote:
On Monday 19 May 2008, Darrel O'Pry wrote:
I just think it wold be cool to support both options, as some items may be user specific. I'm not excluding normal cache_set/cache_get. I'm still think in terms of a more general cacheable module_invoke_all and not specifically hook_*_info.
There may be an advantage to that, but that's separate from what I'm proposing. :-)
It sounds like most people are in favor of something like this, though. Is anyone opposed to some written standards that we can then apply to code?
It still remains to be seen if it's worthwhile.... Iterating over a few functions returning static arrays to to be merged vs a db_query() to be benchmarked... I personally think the db query will probably lose this race.
On Tue, 20 May 2008 10:15:17 -0400, "Darrel O'Pry" <darrel.opry@gmail.com> wrote:
On Mon, May 19, 2008 at 11:18 PM, Larry Garfield <larry@garfieldtech.com> wrote:
On Monday 19 May 2008, Darrel O'Pry wrote:
I just think it wold be cool to support both options, as some items may be user specific. I'm not excluding normal cache_set/cache_get. I'm still think in terms of a more general cacheable module_invoke_all and not specifically hook_*_info.
There may be an advantage to that, but that's separate from what I'm proposing. :-)
It sounds like most people are in favor of something like this, though. Is anyone opposed to some written standards that we can then apply to code?
It still remains to be seen if it's worthwhile.... Iterating over a few functions returning static arrays to to be merged vs a db_query() to be benchmarked... I personally think the db query will probably lose this race.
hook_menu(), hook_views_default_views(), hook_theme(), hook_schema(), and a dozen others would disagree with you. Very often the data isn't just cache_set()ed but parsed out into an easily-queried table. On the memory front, the database wins. --Larry Garfield
On Tue, May 20, 2008 at 11:01 AM, Larry Garfield <larry@garfieldtech.com> wrote:
On Tue, 20 May 2008 10:15:17 -0400, "Darrel O'Pry" <darrel.opry@gmail.com> wrote:
On Mon, May 19, 2008 at 11:18 PM, Larry Garfield <larry@garfieldtech.com
wrote:
On Monday 19 May 2008, Darrel O'Pry wrote:
I just think it wold be cool to support both options, as some items may be user specific. I'm not excluding normal cache_set/cache_get. I'm still think in terms of a more general cacheable module_invoke_all and not specifically hook_*_info.
There may be an advantage to that, but that's separate from what I'm proposing. :-)
It sounds like most people are in favor of something like this, though. Is anyone opposed to some written standards that we can then apply to code?
It still remains to be seen if it's worthwhile.... Iterating over a few functions returning static arrays to to be merged vs a db_query() to be benchmarked... I personally think the db query will probably lose this race.
hook_menu(), hook_views_default_views(), hook_theme(), hook_schema(), and a dozen others would disagree with you. Very often the data isn't just cache_set()ed but parsed out into an easily-queried table. On the memory front, the database wins.
--Larry Garfield
Where are the benchmarks that say the caching is an improvement over the hook invocation in these cases? Are you realistically judging the costs of these database queries on unloaded databases? I'm not knocking it. I use pretty aggressive a caching for imagecache, I just think we also need to measure the impact rather than make assumptions based on other analogous, but not identical implementations. What implementations besides hook_menu build their own easily queried tables? The menu system is designed around much more than simply caching the results of hook_menu. We did have a way to support dynamic variables in URLs, it's quite complicated to choose the proper callback, and there was quite a bit of gnarly logic going on in hook_menu implementations to account for this... So yes it implements and easily queried table now. What implementations besides hook_menu build their own easily queried tables? I hardly think one instance is 'Very Often'. Just caching the results of the return value of a hook_*_info will not save any memory it will just exchange a hook_invocation . I think your assertion regarding memory saving with a cache_set/cache_get is false without taking additional steps. The memory and time would be saved by not loading the files via the registry, but I'm wondering if there is a point of diminishing returns or effectiveness. .darrel.
participants (2)
-
Darrel O'Pry -
Larry Garfield