Hi,

The problem is that ezcontentcache.php can't be used on a huge (4000+ objects) subtree with a reasonnable PHP memory_limit (256M).
=> When using the "clear-subtree" option, $eZContentObjectContentObjectCache is not purged (when looping on ContentObjectIDs), hence the memory hogging when working on big objects and huge subtrees.

For instance :
subtree with 4307 objects (only main_node)

Native ezcontentcache.php :
Peak memory usage: 819,152.7734 KB
Mysql_queries: 47152 queries
( Total script time: 118.5349 sec )

Custom ezcontentcache.php with rough patch included :
Peak memory usage: 10,199.5117 KB
Mysql_queries: 46996 queries
( Total script time: 65.7508 sec )

My example is a run on a subtree of content main nodes, so of course on a "regular" content tree with multipositioned content objects, purging $eZContentObjectContentObjectCache would mean more queries to the database.

Suggestion :

• provide an option to preserve memory usage (over mysql queries) which would follow such a behaviour
  ( - do the same on the "clear-node" option ? )
• provide an option to override the fetch limit of nodes ($limit)

Context: I'm currently working on a project with daily ezpublish content import (add, update, delete) of huge objects (50+ attributes).
I decided to use my own publish operation (disabling content indexing, content cache purge and cache generation) in my import cronjob and opted for a manual purge of content cache via script bin/php/ezcontentcache.php.