[Top][All Lists]

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

Re: casefile random access

From: John Darrington
Subject: Re: casefile random access
Date: Tue, 6 Jun 2006 12:11:14 +0800
User-agent: Mutt/1.5.9i

On Mon, Jun 05, 2006 at 07:57:33PM -0700, Ben Pfaff wrote:

     >      Here's an implementation with a different interface.  If you like
     >      it, I'll check it in.  Let me know.
     > I suppose I can use it.  I'd be immediately following every call to
     > casereader_seek with a call to casereader_read.  In many, but not all,
     > instances the GUI will be reading sequentially.  So the reader will
     > already be pointing to the seeked position.  Will your implementation
     > behave optimally in this situation?  
     Well, not the one I posted, but I took a few minutes to optimize
     it and it should now be OK.
     I figured that sequential access starting at a random position
     would be the norm, hence the preference for a "seek" function.
     > Also, when scrolling backwards there'll be a lot of seeking to
     > 2 positions preceding the current position.  Is it worth having
     > some means of hinting to the casereader that the next read will
     > probably be the case preceeding the case currently being read,
     > instead of the following one?
     > On the other hand perhaps we should leave such optimisations until we
     > know they're justified.
     I doubt the value of trying to optimize this case unless it's a
     real problem.  I'm not even sure what I'd do to optimize it.

I suggest then that you check in your changes when you're happy with
them.  I'll try to get around to using it later this week.  At some
stage I'll run gprof over the gui and find out where the bottlenecks
are; I suspect it won't be in the casefiles.  

The problem with GUIs is, that there is little evidence on which to
base guesses of the `norm'.  The GtkSheet is free to request redraws
on the cells whenever and however it wants. I presume that when it
asks for continuous blocks it does so in top down order (must
check).  But if, for instance, the data sheet is partially obscured by
another window, then when that window is closed there'll suddenly be
request for the data in the middle of the sequence.
Also, if it asks for cells in horizonal order first, then there'll be
multiple requests for the same case.  Which leads me to think that the 
casereader_read function perhaps shouldn't increment its index ---
but I'm not sure.

Anyway, thanks for implementing it.  Let's check it in and see how
well it works. 


BTW, are you still intending to implement the case_reader_clone method
as a separate exercise?

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]