Re: `cpan` unusable on small-RAM machines

[email protected] (Branislav Zahradník)
Newsgroups perl.perl5.porters
Message-ID <CAB=rbOkuWyTCNwdp8Wsk7X-QXuR9Zoqp7Eds_hAhghPqMPsSjg@mail.gmail.com>
>
>
> Fairly early on in its startup, the main `cpan` process loads the
> entire metadata database into memory. It's somewhat big, but that's OK
> - it still fits into memory and doesn't upset things too much (as
> evidenced by the fact that the `cpan> look` command can run just fine,
> for example). Next, it `fork`s itself, before invoking some
> sub-process things via system(). This results in us having *two*
> processes (the original parent and a child), both with that large
> memory footprint. This is still fine - because of Linux copy-on-write.
>
>
Culprit is CPAN::Index.
It work fine if you have sqlite installed - it stores data outside process.
It looks like it is used lazily enough to be able to get rid of data and
load them again.
And it already supports cacheing data using storable.

So for CPAN.pm itself, cleanest way may be providing plugin which will
unload data before fork,
plugin system executed at the beginning of `test` command is already
supported.

Brano
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.