dpkg reviewed
I've been looking over the dpkg lib code wondering why it uses so much
memory. I have Debian on an old laptop with 12MB of RAM.
This is all on i386...
available + status = 5.5MB, but dselect uses considerably more (about
14MB)
Very little digging around got me a couple of memory leaks.
Unfortunately not the whopper I was expecting, but it does reduce the VM
footprint by about a megabyte. Trivial patch for these at the end of
this message.
My next move was to cache the strings copied from Section lines rather
than allocating fresh memory for each new Section line. This freed
another 200k -- there are 79 unique sections but 5765 packages.
Replacing nfstrsave("") in lib/parsehelp.c with a pointer to a static
empty string saved another 130k. Taking "long double d" out of
lib/nfmalloc.c's "union maxalign" saved another 850k. The largest type
stored in nfmalloc space (by libdpkg) is a pointer.
Now, from my studying of the contents of lib/, the pool of nfmalloc
memory should be approximately equal to the combined sizes of available
and status (ie. 5.3MB). However the nfmalloc pool is nearly 6.8MB in
size after my little tweaks. The difference amounts to about 275 bytes
per package.
Anybody want to speculate where the difference goes?
(Passing comment: dselect is evil. It makes another copy of most of the
data that's already in the data segment.)
--- lib/fields.c~ Mon Oct 25 19:52:12 1999
+++ lib/fields.c Fri Oct 6 23:38:34 2000
@@ -377,5 +377,6 @@
if (!*p) break;
p++; while (isspace(*p)) p++;
}
+ varbuffree(&depname); varbuffree(&version);
}
--- lib/dump.c~ Thu Oct 21 11:38:39 1999
+++ lib/dump.c Fri Oct 6 23:40:08 2000
@@ -222,6 +222,7 @@
varbufaddc(&vb,'\0');
if (fputs(vb.buf,file) < 0)
ohshite("failed to write details of `%.50s' to `%.250s'", pigp->name, filename);
+ varbuffree(&vb);
}
void writedb(const char *filename, int available, int mustsync) {
--
Paul Martin <pm@zetnet.net> (work)
<pm@nowster.zetnet.co.uk> (home)
Reply to: