Load function on Windows is significantly slower than on Linux

I ran following script on GNU Octave, version 6.2.0:
tic
A = rand(1000, 1000);
toc

tic
save(‘A.txt’, ‘A’);
toc

tic
B = load(‘A.txt’);
toc

And got following results:

Windows 10:
Elapsed time is 0.010767 seconds.
Elapsed time is 1.90084 seconds.
Elapsed time is 19.3035 seconds.

Ubuntu 20.04:
Elapsed time is 0.011447 seconds.
Elapsed time is 0.636885 seconds.
Elapsed time is 0.873379 seconds.

So, on Windows load function is more than 20 times slower than on Linux (20 seconds vs. 1 second).

Сan anyone please confirm these results and explain what this delay may be related with? (and can this delay be significantly reduced?)

Linux is superior to windows. Try saving to binary format.

save("-binary", "A.obin", "A");
1 Like

Like that comment.

@Mithridat: Can you try the same benchmark you did for text files with binary files by adding the -binary option and report? If it resolves the issue then you can change your default settings to always use binary mode by adding this to the .octaverc initialization file

save_default_options ("-binary");

For binary files got following results:
Windows 10:
Elapsed time is 0.012146 seconds.
Elapsed time is 0.00397396 seconds.
Elapsed time is 0.0132461 seconds.

Ubuntu 20.04:
Elapsed time is 0.019496 seconds.
Elapsed time is 0.00729489 seconds.
Elapsed time is 0.00489092 seconds.

So, it’s hundreds of times faster than for text files, there are almost equal results for both operation systems and file size decreased from 20 megabytes to 8 megabytes.

Thank you all!

But can anyone please express his ideas about such huge advantage of binary files over text files and what Windows delay for text files may be related with?

When files are opened in text mode the operating system may need to do conversions between the file encoding (UTF-8, etc.) and what Octave binary expects. That might be a source of the slow down.

In any case, could you file an issue report at bugs.octave.org? It’s a low priority—since there is a workaround of just using binary mode—but it might be something easy to fix.