[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Slowness in function 'open'
From: |
Daniel J Sebald |
Subject: |
Re: Slowness in function 'open' |
Date: |
Fri, 22 Jun 2007 22:42:13 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 |
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