Re: Slowness in function 'open'

[Jordi Gutierrez Hermoso]

On 22/06/07, Daniel J Sebald <address@hidden> wrote:
> > > On 22-Jun-2007, Jordi Gutierrez Hermoso wrote:
> > 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.

I see that you've done quite a bit of investigation on where the
slowness is, but I'm writing this response before reading your
thoughts. I don't think the double pass is the slowest part. My
current guess is this: jwe wrote some basic I/O and string formatting
functions for reading while I used C++'s standard library functions to
do the same, and those library functions have already been optimised
much more than whatever functions jwe could have written (and before
jwe gets defensive, no, your coding doesn't suck; it's just that C++
standard libraries are very, very good, mostly because they are used
so much more  than Octave and have many more people working on them).

I also realised that perhaps that wall time may have also been
counting however long it took Octave to make the system call. I
tic-tocked each operation ten more times, and my function call, except
for the first call, was faster than Octave's by about a factor of ten.
It still doesn't quite have all the requirements needed for Octave,
though. I need to account for commas as whitespace and match the inf,
nan, na, tokens case-insensitively. I'll try that later and see if I
still get an improvement.

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

I was confused. I thought that jwe wanted Octave to work on machines
without IEEE arithmetic. I was further confused on this when I saw
somewhere in the code (lo-ieee.cc, I think) that Octave's idea of Inf
and NaN was DBL_MAX.

> > 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

I'm really warming up to this guess idea. Store the data in an
std::vector, which is also optimised to resize smartly in case the
initial guess was wrong. It has list-like push and pop functions that
will resize the underlying array in case more memory is needed. You
can also tell it how much space to allocate for contiguous storage,
which is where our initial guess would go.

I'm a big C++ standard library fan. :-)

>  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

Like C++? ;-)

> where one has no concern for the expense of setting up a stack and
> calling a function.

The stack overhead can be avoided by inlining the function. I think
this is a C++ extension to C.

> Short macros aren't too bad, but long ones usually are better done with
> a function.

I can think of very few instances in C++ where macros are absolutely
necessary, and all the ones I can think of are due to a shortcoming of
C++. One of them is BOOST_AUTO, which is scheduled to be fixed in
C++09:

    http://www.boost.org/doc/html/typeof/refe.html#typeof.auto

You may know of other examples. But really, macros are bad, bad, bad.
They mess around with your code before the compiler even sees it and
can introduce very nasty and obscure bugs. I guess if you use them and
the code works, then that's that, and I've seen C code with consistent
use of macros that looks ok to me (the GSL comes to mind). For my C++
style of coding, however, I very rarely use them.

- Jordi G. H.