pspp-dev
[Top][All Lists]
Advanced

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

Re: casefile random access


From: Ben Pfaff
Subject: Re: casefile random access
Date: Mon, 05 Jun 2006 19:57:33 -0700
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

John Darrington <address@hidden> writes:

> On Mon, Jun 05, 2006 at 05:38:53PM -0700, Ben Pfaff wrote:
>      John Darrington <address@hidden> writes:
>      
>      > If you're able and willing to write a random access casereader, then
>      > that will certainly make the gui code simpler.  I've got a change
>      > almost ready to commit, which will remove the GUI's hard limit  on the
>      > number of variables.   The next major step for the GUI is to unlimit
>      > the number of cases. So I'm just about ready to use such casereader.
>      >
>      >
>      > My idea of the interface would be something along the lines of the
>      > following, but you may have better ideas.
>      
>      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.
-- 
Ben Pfaff 
email: address@hidden
web: http://benpfaff.org




reply via email to

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