[development] MYSQL queries and Modules

[nan wich]

Yes, I meant drupal_static(); I just couldn't think of the function when I wrote 
that (I haven't done that much D7 coding yet).

Ah, see now you say that 10% of hook_init's are appropriate, so telling someone 
to always avoid it is bad advice. In all the coding that I have done, I have 
used hook_init() maybe three times (twice I know for sure). And one was largely 
a toss up between hook_init() and hook_boot() and I can guarantee was needed. 
And you probably add hook_exit() to the list of questionable usage.

In the case where I created my own cache file, it was more an attempt to "help" 
the database keep the data available because rebuilding the data 
(taxonomy-based) could get quite heavy in certain circumstances. When I convert 
the module to D7, I may not need any of that because field data may already be 
cached any way. As a matter of fact, 90% of the module may no longer be needed.
 
Nancy
 
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.



________________________________

From: Pierre Rineau

If you mean drupal_static() 

Sometimes, but when you are writing a hook_init(), in 90% of the cases
you are wrong.

> Indeed using cache is a balancing act. When I added caching to one of
> my modules, I checked its performance impact. Using the main cache
> table made things worse because cache_get queries were taking longer
> than no caching at all. So I created my own cache table and it solved
> the performance issue that I was attempting to fix. I still don't
> think it was a good substitue for a properly tuned database server,
> but few people have those.

Using a different cache because it increases performances is not always
the good way to go. If fetching a cache in global cache table is slower
than rebuilding your data, then you should probably *always* rebuild it.
Because if you are slower in the cache table than in your own doesn't
mean you solved the problem by doing the custom table, it only means
that you delayed its negative effects because as soon as the site will
scale in term of data volumetry, it will then happen again.

By using this kind of judgement instead of separating logically caches
(critical/always used cache such as bootstrap and menu, or heavy and
ponctual caches such as aggressive page cache) you break the sysadmin's
work which is to distribute those bins over different cache backends
(memcache, apc, xcache, database, ..) depending on the data volumetry
and physical environment measured performance impact.

> Nancy

Pierre.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20110227/58ee4c04/attachment-0001.html