[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: casefile.c revision

From: John Darrington
Subject: Re: casefile.c revision
Date: Sun, 5 Jun 2005 11:42:47 +0800
User-agent: Mutt/1.5.6+20040907i

On Sat, Jun 04, 2005 at 05:07:26PM -0700, Ben Pfaff wrote:
     John Darrington <address@hidden> writes:
     > From the programmer's perspective (ie. the person writing rank like
     > commands) I think that A is the best.  The only thing is, one has to
     > bear in mind that casereader_clone()/ casereader_destroy() will be
     > called at least once per case, so some optimisation would be in order
     > here too --- perhaps a memory pool dedicated to each casefile would be
     > a good idea.  
     Here is what I imagine to be the common case: only one case, or a
     few, with equal values that must be grouped together.  This group
     will typically be within a single disk buffer, because I expect
     that a single disk buffer will typically hold several cases.
     I think I could make the common case very fast.
     > Also, I suppose it'd not make sense to clone a destructive
     > reader?
     I think that we'd want to make that work, actually.  We can only
     discard cases that no existing casereader can read, but most of
     the time that's most of the cases.
     If you like this approach, I can implement the casefile parts
     pretty easily.

Well let's do it then.  But don't let us hold up the release of 0.4.0
for this.


PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]