[development] RFC: info hook standardization

[Darrel O'Pry]

On Tue, May 20, 2008 at 11:01 AM, Larry Garfield <larry at garfieldtech.com>
wrote:

>
> On Tue, 20 May 2008 10:15:17 -0400, "Darrel O'Pry" <darrel.opry at gmail.com>
> wrote:
> > On Mon, May 19, 2008 at 11:18 PM, Larry Garfield <larry at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080520/ed908777/attachment-0001.htm