Re: point_lun is slow

[George McCabe <george.mccabe(at)gsfc.nasa.gov>]

hi david,

i am reading individual detector array elements from frame sequential
image data.  the file is too large to be read completely into memory.  i
wrote three different algorythms to compare: one 'pages' through frames
using assoc() and keeps groups of pixels, one chunks through groups of
frames with point_lun & readu, and lastly, the algorythm in question,
reads each 2 byte piece indiviually.  the number of program steps in the
last approach is much higher but, the amount of data read from disk is
much smaller for select sets of elements.  i did not have a way of
estimating the speed of each part of these procedures a priori.  if
there are no subtleties to using point_lun in a unix file system that
can change performance significantly (buffer sizes, ...?) the answer to
my original question, what is faster, is known.  what i was fishing for
was information about idl and details related to accessing files which
might be relevant to this task.

george

data David Fanning wrote:
> 
> George McCabe (george.mccabe@gsfc.nasa.gov) writes:
> 
> > reading from a data file at regularly spaced byte locations, 2 bytes at
> > a time using point_lun - my program is abnormally slow.  i don't have
> > enough experience to guess whether the poor performance is inherent to
> > point_lun & readu approach or if there are options which are affecting
> > execution adversely.
> >
> > i'ld appreciate any thoughts on the topic which might lead to a
> > solution.
> 
> Can you give us some idea about why in the world you
> are doing this!? :-)
> 
> There is probably an easier (and MUCH faster) way
> if I had some idea what you were trying to do.
> 
> Cheers,
> 
> David
> 
> P.S. You aren't doing this in a loop are you? :-)
> 
> --
> David Fanning, Ph.D.
> Fanning Software Consulting
> Phone: 970-221-0438 E-Mail: davidf@dfanning.com
> Coyote's Guide to IDL Programming: http://www.dfanning.com/
> Toll-Free IDL Book Orders: 1-888-461-0155