Why takes xlsread about 4 times longer than dlmread?

Hello,

my program takes data from a variable number of xlsx data, I´ve seen that in some of the xlsx data a date such like 27.January appears instead of the value, therefor the dlmread command is not longer usefull because of the non-numeric data, right? So, i´have chosen xlsread to have a more stable program, but the xlscommand takes more than 4 times longer. I compared it with the tic-toc command. What is the reason behind that difference in time?

best regards

[Rik]

I would assume xlsread has a lot more parsing to do before it can return a result to the user, so it doesn't surprise me that the processing times are very different.

Answer 1

[Walter Roberson]

On MS Windows with Excel installed, xlsread() communicates with Excel to do the reading. Numeric date information is detected (days since the beginning of 1900 or 1904, depending) and converted to character versions of the dates. This does not mean that the data is stored internally as character. If you tell xlsread() to use 'basic' mode or you are not using Windows with Excel installed, then numeric date information is returned instead and needs to be converted.

dlmread() simply does not apply to xlsx . xlsx files are internall zip compressed directories of multiple xml files that represent data mostly in text form. dlmread() can only parse delimited columns of text, which xml files are not.

If you are comparing reading csv files to reading xlsx files, then you should take into account the overhead of communicating with Excel (at least on Windows). Excel might potentially have better optimized csv import routines (that is, one could speculate that Microsoft might have hand-written and tuned the code for this purpose), but it still takes time to establish communications and transfer data. Any speed advantage that Excel might have for importing csv files would therefore not be expected to show up unless you had relatively large files.

You might want to also experiment with readtable().