<br><div class="gmail_quote">On Tue, May 20, 2008 at 11:01 AM, Larry Garfield <<a href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c"><br>
On Tue, 20 May 2008 10:15:17 -0400, "Darrel O'Pry" <<a href="mailto:darrel.opry@gmail.com">darrel.opry@gmail.com</a>> wrote:<br>
> On Mon, May 19, 2008 at 11:18 PM, Larry Garfield <<a href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a>><br>
> wrote:<br>
><br>
>> On Monday 19 May 2008, Darrel O'Pry wrote:<br>
>> > I just think it wold be cool to support both options, as some items<br>
> may<br>
>> be<br>
>> > user specific. I'm not excluding normal cache_set/cache_get. I'm still<br>
>> > think in terms of a more general cacheable module_invoke_all and not<br>
>> > specifically hook_*_info.<br>
>><br>
>> There may be an advantage to that, but that's separate from what I'm<br>
>> proposing. :-)<br>
>><br>
>> It sounds like most people are in favor of something like this, though.<br>
> Is<br>
>> anyone opposed to some written standards that we can then apply to code?<br>
><br>
><br>
> It still remains to be seen if it's worthwhile.... Iterating over a few<br>
> functions returning static arrays to to be merged vs a db_query() to be<br>
> benchmarked... I personally think the db query will probably lose this<br>
> race.<br>
<br>
</div></div>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.<br>
<font color="#888888"><br>
--Larry Garfield<br>
</font></blockquote><div><br> <br>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.<br>
<br></div></div>What implementations besides hook_menu build their own easily queried tables?<br><br>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.<br>
<br>What implementations besides hook_menu build their own easily queried tables? I hardly think one instance is 'Very Often'.<br>
<br>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.<br><br>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.<br>
<br>.darrel.<br>