[kronolith] Excessive memory usage with Kronolith

[Chuck Hagenbuch]

Quoting Kevin Myer <kevin_myer at iu13.org>:

> However, now when I attempt to login to my HEAD install, the loading of the
> Kronolith portal block is bringing Apache to its knees.  Memory usage climbs
> and climbs, until it hits my preconfigured limit (2Gb) or I manually HUP the
> process.

Does the block actually output, or does there seem to be a loop that 
doesn't exit?

Does the production install display the same calendar data in the 
portal block without difficulty?

> I did some profiling with apd and here's what I found, for a trace of the
> Kronolith summary Block (this is up to the point that I HUPped the process):
>
> 300,000 calls to in_array
> 300,000 calls to is_a
> 200,000 calls to horde_date:comparedate
> 100,000 calls to mktime, is_array, horde_date::horde_date,
> horde_date::timestamp, Kronolith_event_sql::isallday,
> kronolith_event_sql::getid, horde_date::comparedatetime
>
> I have a total of 546 events in my calendar that I imported.
>
> So, any pointers on where to look further?  I did wipe the entire 
> database for
> this install and started from scratch.  Its only when I try to access the
> calendar that unhappy things start to happen.  Also tried using just the past
> month (only 20 events) - same problem.  So, is it possible I have a bad event
> that is throwing things off?

So does this happen for regular calendar views as well, or just the 
portal block? _Which_ portal block (there are 4 or so), and with what 
exact settings? Does it happen in the day view?

What's the overall set of code being run that generates all those 
calls? Etc...

-chuck

-- 
"But she goes not abroad in search of monsters to destroy." - John 
Quincy Adams