On Thu, 20 Jul 2006 20:39:12 -0700, Daniel Burrows <[EMAIL PROTECTED]> wrote: > There are things that could be done to adjust the storage of the > descriptions list, of course. For instance, I wonder if a suffix tree > or some similar data structure would be helpful. I don't really want > to rewrite the whole apt caching layer, though. > > Probably the reason aptitude pulls everything into RAM is that it > walks over the whole cache to build some of its structures on startup. > I suppose we could get some speedup by using a binary cache of those > too. For instance, the debtags stuff doesn't change unless the lists > change, so there's no need to build it every time. Also, currently > std::sets are used; probably we could just use those to build it the > first time, but actually store it as a sorted list. Other optimizations > are also possible (e.g., indexing into a common list of tag strings), > depending on how much time you want to waste on them.
For simple command-line use, the whole debtags component is irrelevant, anyway -- factoring it out so it's not done at all for a simple "sudo aptitude install -y deborphan" would perhaps already be enough to make it palatable again. FWIW, I've been trying to use aptitude as a straight replacement for apt-get, but on my 64Mb P133 this is no longer feasible. I'm afraid to run aptitude at all on this machine because oom-killer might zap some essential system daemon. This is on Ubuntu Dapper with main+universe+backports, BTW. When I was running Woody on the same hardware but only 32Mb RAM, Xfree was mostly usable even while apt-get was installing something. Now I basically have to choose between Emacs or aptitude, and forget about X altogether ... But I am about to switch back to apt-get + deborphan if I can get used to the idea. Maybe then I could try running X again. /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
