Re: Sequential vs. Random access

[Ben Pfaff]

John Darrington <address@hidden> writes:

> On Wed, Jan 31, 2007 at 07:10:13AM -0800, Ben Pfaff wrote:
>      John Darrington <address@hidden> writes:
>      
>      > On Tue, Jan 30, 2007 at 10:30:43PM -0800, Ben Pfaff wrote:
>      >
>      >      So I'm not proposing to
>      >      encourage use of random access where it's not necessary.
>      >      
>      > Would it therefore be worth having a flag passed to the casereader
>      > constructor which declares whether or not the casereader performs
>      > random access? 
>      
>      What's the intended usage?
>
> Well I suppose it's similar to declaring a variable  const.  If we
> have something similar to 
>
>  struct casereader *sequential_reader = create_casereader (SEQUENTIAL);
> or 
>  struct casereader *random_reader = create_casereader (RANDOM);
>
> and the implementation enforces sequential-only access unless random
> is requested, then there may be two possible advantages:
>
> 1.  By declaring a reader sequential, we can trap inadvertent random
>     access.  In code reviews, any use of random readers is obvious,
>     and the reviewer may be able to suggest a faster method using
>     sequential access. 
>
> 2.  Maybe the implementation can make internal optimisations if it's been
>     passed the SEQUENTIAL flag?

These are good ideas but I don't think that they apply to the
implementation.  First, casereaders are generally created from
a casewriter, by reusing the data structures or file that the
casewriter produced.  So you don't have a chance, at the point
where the casereader is created, to decide how to structure it
for use for sequential or random access.

I think it'll be obvious when random access is in use, in any
case.  To access casereader data sequentially, you use
casereader_read; to access it randomly, you use casereader_peek.
The former is likely to be more efficient than the latter in some
circumstances.  I think that's all there is to it.
-- 
"The road to hell is paved with convenient shortcuts."
--Peter da Silva