Hi, On Sun, 2008-07-06 at 15:26:02 +0200, Raphael Hertzog wrote: > On Tue, 24 Oct 2006, Michel Lespinasse wrote: > > "dselect select" seems to take about 48 MB while displaying the > > packages, this causes a small-memory system (32MB) to go heavily into > > swap. > > > > A quick run with valgrind --tool=massif reveals that about 15MB are > > allocated by 'newpad'. Apparently dselect creates a 20000-line ncursed > > pad to hold the package list. Since the same information is also present > > as part of the in-memory package database, it might be possible to save > > the memory by generating a smaller pad for just the part of the list > > that's being shown at any given time. > > This change is reasonable IMO. I updated the patch and pushed it here: > http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/bug395140-dselect-memory-usage > > I tested it and it works fine apparently. I'll merge it if nobody > expresses any concern.
Seems fine to me as well, except for the few missing spaces and more than one statement on the same line. > On Fri, 27 Oct 2006, Michel Lespinasse wrote: > > The attached patch helps with low-memory performance by implementing > > segregated memory storage. A separate obstack is used for allocating > > information related to the Installed-Size, Origin, Maintainer, Bugs, > > Architecture, Source, Filename, Size, MD5sum, MSDOS-Filename and > > Description fields, as well as any arbitrary field contents > > (which these days seems to include SHA1, SHA256, Tag and Task fields). > > I don't think that we want such a change. It will apply both to dselect > and to dpkg, and it's probably not desirable in general. It would be > fine-tuning generic code for a specific use case and that doesn't make > sense. I think the idea behind this change is good, some of those fields you listed are not used internally by dpkg on the most intensive operations, which mostly use the dependency information. But I didn't like the implementation, I think generalizing a bit the non-freeing allocating code would be better anyway, there's for example direct usage of obstacks in src/archive.c, that should be abstracted away. I wrote some initial code the other day for that generalization, should cleanup and commit, afterwards we could consider this patch. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
