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.
