[SP-pm] "leak" no DBIx::Class?

[Stanislaw Pusep]

Trazendo pra cá a conversa com @edenc no Twitter :)
Observei que um script meu (bastante simples) estava torrando 6GB de RAM
mais 5GB de swap...
Consegui isolar o seguinte trecho porcalhão:

my $images = $schema->resultset('Image');
...;
while (my $url = <>) {
    ...;
    $images->find_or_create(
        {
            sampler_uid => $obj->uid,
            url         => $url,
        },
        { key => 'images_url_idx' }
    );
}

Curiosamente, posso substituir find_or_create() por apenas find() e o
resultado é o mesmo: acréscimo de alguns KB no processo para cada operação.
Como tenho meio milhão de registros, deu no que deu.
Tive que trocar por isso daqui e funcionou perfeitamente:

my $images_insert   = $schema->storage->dbh->prepare(
    'INSERT INTO images (sampler_uid, url) VALUES (?, ?)'
);
...;
while (my $url = <>) {
    ...;
    eval {
        $images_insert->execute($obj->uid, $url);
    };
}

Antes disso, suspeitei que tivesse algo a ver com AutoCommit e encapsulei
com txn_do() a cada 100 registros; deu na mesma.
Também suspeitei do prepare_cached(), porém isso não faz o menor sentido,
pois o statement é o mesmo para todas as queries. Anyway, tentei
limpar $schema->storage->dbh->{CachedKids} periodicamente e também não
adiantou.
Por fim, tentei ver o que acontece xeretando através do Devel::Size. De
fato, o objeto do ResultSet cresce indefinidamente. Porém todas as minhas
tentativas de serializar o mesmo e descobrir o que está acontecendo via
diff foram frustradas :(
Any ideas?

ABS()
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20111111/929d34dd/attachment.html>