Best way to acess external config data (load mat file vs import data vs fscanf etc. )

Question

Mathieu 2014-6-13

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/134124-best-way-to-acess-external-config-data-load-mat-file-vs-import-data-vs-fscanf-etc

回答： Pritesh Shah 2014-6-17

Greetings, I need to store some external parameters in a configuration file (not more than 50 lines). It is not yet defined how many subfunction will need to have access to it but the overall speed will be important. The whole application will be compiled in the end.

I found multiple ways to do this but I am not sure what is the best way: I could load a mat file, read an ascii txt file, a csv and so on (and all this with multiple possibilities).

What is the best (most efficient) way to do this ?

Thanks.

5 个评论
显示 3更早的评论隐藏 3更早的评论

dpb 2014-6-16

编辑：dpb 2014-6-16

在 MATLAB Online 中打开

A stream file is what is often called "binary" -- fread/fwrite

I think the structure of a configuration object is the far cleaner solution--it encapsulates the changes inside the structure and is, therefore, far less prone to rampant changes in code at least isolating the interfaces.

Again, unless you insist on embedding this i/o operation deeply within a nested loop or somesuch, it's almost certainly to be of no never-mind in performance overall; it's just unwise to not do as good a job of factorization and encapsulation as feasible at the git-go rather than start with a bad factoring from the beginning.

If there are subsections that need disparate data, create specific structures or the like for them to minimize the amount of data being passed around rather than reload stuff randomly.

I'd say likely (but only timing with a specific file size/structure can prove it) the order would be

fread
load
fscanf
...

The higher-level functions trailing in no known order but stuff like importdata that are generic and do a lot of testing to handle anything automagically will likely bring up the rear and possibly by a fairly wide margin.

Mathieu 2014-6-17

Thanks a lot!

I also intuitively thought importdata would be slow, but for some weird reason associated it with the speed of "load" that you implied. It makes complete sense this way.

I use fread/fwrite with virtual com ports but have no idea how to use that with local files. Anyhow, I don't think it is worth to investigate now.

I'll start with a load and will switch to fscanf if needed.

Thanks again for the support.

dpb 2014-6-17

The biggest difference in speed between the classes is whether they're formatted or unformatted files. The overhead for formatted files is first there's many more bytes/numeric value and secondly it takes compute-time to do the conversion from/to internal storage to the ASCII representation.

For formatted files the higher-level, more convenient forms TMW supplies have all the extra processing and logic built into them that make them more convenient to use but that also comes at a price of far more complexity in the processing. load is slightly more complex than a pure stream of bytes owing to the fact it also saves the structure and the information associated with the variable(s) whereas all of that is your responsibility if you simply write an array as the byte stream.

Similarly, if use fscanf by itself, all the formatting and structure in the file is written explicitly so there's no additional internal logic. If you use one of the more convenient forms then they eventually get down to the final call to the i/o but they have (a varying amount of) flexibility built in so again, that costs something in performance in payback for the convenience (there is no free lunch).

OTOH, for the size of the data you're talking about, I'll reemphasize that write the code for ease of maintainability and clarity of expression first; the amount of data you're talking about is so minimal as to be of no concern for execution time or storage space (again, presuming the avoidance of doing the same thing over and over and over...).

请先登录，再进行评论。

请先登录，再回答此问题。