Re: Slowness in function 'open'

[Daniel J Sebald]

Daniel J Sebald wrote:

> I tried a "save -binary testb.m A".  In that case "load testb.m"
> seems to be very quick.  So, would it be feasible to create a
> temporary binary file on the first pass?  It seems that all that is
> needed is to move
>
>  d = octave_read_double (tmp_stream);
>
> inside get_lines_and_columns()'s loop along with saving to a binary 
> output stream.  Then perhaps an existing binary read method could be 
> reused on the temp file.
>
> Is it worth Jordi trying that approach?

I tossed a print command in between the two loop passes.  
get_lines_and_columns() takes roughly 1/3 of the time.  So octave_read_double() 
is a good part of the computations, and that is no surprise.  As John said, 
there is inf_nan_na and the fact there are a number of variations on a 
complex/real/imaginary number to consider.

If octave_read_double is where a lot of time is spent (should use a profiler to 
pinpoint), that would mean moving it to the first loop still won't cut overall 
time drastically.

What's left?  I don't know, if the file is very big, could first scan it in 
binary mode for any non-alphanumeric characters.  If there are none (i.e., no 
comments, no imaginary), then could use a less computationally intensive 
algorithm than octave_read_double() implements.

Go binary.

Dan