in reply to Clean Code - What a mess...

This is a longshot...

Maybe you're actually bloating the cache that's created when you use $database->prepare_cached(). I suppose that would depend on how many lines of input this script sees.

I wonder why you would even want to cache the results of SQL statements such as CREATE TABLE IF NOT EXISTS. Does this help? I would have guessed that the cache was more useful more SELECT queries.

Anyway, as a longshot, try turning those into $database->prepare() instead, and see if it helps any.

Even better, substitute placeholders for the variables. That way you can prepare() the statements once and execute() them with the correct parameters each timne through the loop. It may not affect the memory leak, but it's useful in many ways.

buckaduck

Replies are listed 'Best First'.
Re: Re: Clean Code - What a mess...
by PyroX (Pilgrim) on Nov 29, 2001 at 04:20 UTC
    This application sees about 200,000 lines of input per day, so you think that is it? Tha cache is just getting to be too much?
[reply]
      The way that prepare_cached works is that it uses your entire SQL statement as the key to a hash (the value is the statement handle). So if statements differ in any way (even whitespace), then you are storing another key/value pair in the statement cache (and the database creates another cursor if the database supports cursors). With 200,000 lines of input and no placeholders in sight, you are abusing prepare_cached and are wasting memory. If you use placeholders, then the only difference in your cached statements will be the table names, and you shouldn't run out of memory (assuming there aren't too many table names).
[reply]

In Section Seekers of Perl Wisdom