This is a quick tip for people running scripts (or cron) with a lot of node_load.
If you call node_load, it does some static caching keeping the node object for the duration of the script to save some calls to the database.
<?php
function node_load($param = array(), $revision = NULL, $reset = NULL) {
static $nodes = array();
if ($reset) {
$nodes = array();
}
// loading the node...
return $node;
}
?>
If you have a lot of those node_load calls, this needs a lot of memory. Megabytes.
But node_load was built with a reset option. So if you run it with the $reset parameter set to TRUE, it will clear its static cache. And your code is no memory hog anymore.
Comments
It looks like this same memory issue may appear when importing lots of content that contains CCK fields (#736440).
I have exactly the same problem where memory gets exhausted as it consumes almost 800 MB. Will need to check if this helps
Sure, this helps.
But the really bad one is this: taxonomy_get_tree(), which does a lot of static caching, and has no reset parameter.
If you have a lot of nodes and/or freetagging, then things will blow up because PHP uses more and more memory all the time.
Thanks Davy, that's a good tip. I often find myself in positions where I write scripts where I bootstrap Drupal to do large operations of node creation and such (ie., importing all the content from a legacy site to a new Drupal install) and in some cases iterating over all existing nodes with node_loads - the node cache in those cases costs more than it saves. I hadn't noticed the reset parameter.
If you don't do any serious node actions on cron, this won't apply to you.
i have a scheduled cron tab that simply hits cron.php once an hour...
wondering is there some way to incorporate the info in your post to improve cron performance?
please advise and thanks!
vincent, in buffalo
http://basicmagic.net
Post new comment