On Sun, 06 Jul 2008, Guillem Jover wrote:
> Seems fine to me as well, except for the few missing spaces and more
> than one statement on the same line.

Ok, will fix before merge.

> > 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'm not convinced that it will help dpkg a lot since it always
has to write the status file back and it will access all the fields at
this point of time anyway. Of course this also applies to dselect but
since it's an interactive program, it's logical to have different
considerations for interactive responsiveness.

> I wrote some initial code the other day for that generalization, should
> cleanup and commit, afterwards we could consider this patch.

You write too many things in parallel. :-)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to