Re: Slowness in function 'open'

[Daniel J Sebald]

> On 22/06/07, John W. Eaton <jwe at bevo.che.wisc.edu> wrote:
> > On 22-Jun-2007, Jordi Gutierrez Hermoso wrote:
> >
> > | I can't quite understand what they're doing at first glance. But if
> > | the problem is simply to read a matrix ASCII file, looks like there
> > | might be a better way to do it.
> >
> > Before comparing speed, let's make sure we are talking about the same
> > function and that they handle the same set of requirements.
>
> I made some changes:
>
>      http://platinum.linux.pl/~jordi/octave/matrix-read-example.tar.gz
>
> The only additions are in the operator>>(...) function for matrices in
> linalg.cpp. My function is still slightly faster than Octave's, but it
> naturally slowed down a little:
>
>      octave2.9:3> tic, load A.m; toc
>      Elapsed time is 7.072884 seconds.
>      octave2.9:4> tic, system("foo"); toc
>      Elapsed time is 2.766716 seconds.

Try to identify where the time difference is.  So, is your time shorter because 
the algorithm is doing a single pass?  Sometimes the underlying C function 
doing the reading can be slow, e.g., fscanf().  Is there a fundamental 
difference between the two methods in that regard?


> >   4. handle reading Inf and NaN values even when the underlying C/C++
> >      library does not
>
> Oy. That's complicated. Why do we need that? You mean we can't assume
> std::numeric_limits<double>::quiet_NaN() will yield the value we want?
>
> A standards-abiding C++ implementation has to report with
> std::numeric_limits<double>::has_quiet_NaN() if it has decided to not
> adhere to IEC 559.

Isn't IEC 559 a binary standard?  In your post you mentioned ASCII.  I'm not 
following.


> The only std::list-specific functionality my code uses is that it
> avoids the resizing problem that you solved with a double-pass. In a
> way, it does this by hogging up space. Maybe there's a better
> tradeoff.

You could make a rough guess based upon reading a line of data and then 
guessing the matrix size based upon the file size and number of characters per 
line.  It may not be accurate in cases where the number of characters per 
number varies, would just have to expand the memory and mem-copy.  I'd think 
that an based on copying memory, if done right, would be faster.  Memory copy 
wins out over disk access.


> > > | I try to always avoid macros, for instance. To
> > > | paraphrase Stroustrup, macros are a deficiency in the code, the coder,
> > > | or the coding language. ;-)

That's true for high level languages where one has no concern for the expense 
of setting up a stack and calling a function.  Octave may fall in that 
category.  Short macros aren't too bad, but long ones usually are better done 
with a function.

Dan