Re: Too Many Packages [was Re: Splitting locales...]
On Mon, 9 Oct 2000, William Lee Irwin III wrote:
> Anyone else care to explain what performance problems there might
> be in the package management tools, perhaps with some concrete evidence?
> I suspect if there is algorithmic wizardry to be had in this arena, it
> will fall in the realm of the dependency analysis or perhaps concurrently
> performing various phases of package installations.
Look at libapt.. It uses around 1.1 meg of ram, and the most noticable
time wastes are the loading of the 9 meg of package files (which is done
once after update, generally) and the evaluation of the 38000 dependencies
on startup. The latter has become a bit slow of late due to the increased
use in versions, the code needs to be retuned somewhat to take advantage
of the fact that most versions are the same.
The biggest performance hinderence right now is that dpkg cannot do more
than one thing at once, so you see APT call it many many times and take
the 'loading file list' hit for most of them and it's status file load for
them all.
Someone else posted a disection of dselect that seemed to imply it was
just poor programming style that it is so slow and uses so much memory. I
know the APT based GUIs typically run at about half the memory usage of
dselect and are much faster all round.
It seems to me, if someone really wants a fast+lean dselect the thing to
do is just re-implement it's GUI on libapt - it would be pretty easy
actually, but I'm biased :>
Jason
Reply to: