[Octave-bug-tracker] [bug #56489] System freeze due to Excel import

[Philip Nienhuis]

Follow-up Comment #6, bug #56489 (project octave):

Thanks for testing.

(1) I've seen the system clock stall as well when I was declaring huge arrays
(in other SW), at one time I left my system running overnight to see it
responding again the next morning. Stopping the SW then again introduced a
quite conspicuous hang :-)

(2) Yes I know that invoking Excel/COM is about 10 times faster (with
reasonably sized spreadsheets) than OCT (native octave code). Next slower are
the Java-based interfaces. OXS (OpenXLS, only for .xls) is the fastest of them
by a small margin, POI the slowest.

What do you want me to do with this bug report now that you have an
alternative?
I'm willing to look into it; if so, could you upload your spreadsheet
somewhere (wetransfer, Google drive, whatever) so that I can try myself?
Otherwise I'll close this bug report with "won't fix" or maybe just lower
priority and set it to "postponed", as the size of your Excel file is not very
common.

FYI:
The relative small size of some output arrays is due to xlsread (or rather its
helper functions) strip the num, txt and raw arrays of empty outer rows and
columns after processing. They're much bigger while reading.
You can try again without stripping as follows:

[NUMARR1, TXTARR1, RAWARR1, LIMITS1] = xlsread ('v201981_rawdata.xlsx', 1, [],
'OCT', struct (" strip_array", 0)); ## watch out for line break; all on one
line

and then run "whos".
As I wrote the size of RAWARR reported by "whos" is deceiving, its real RAM
occupation is a multiple, up to tenfold.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?56489>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/