[bug #68091] Inefficient Integer Data Loading from MAT-Files

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only notification stream.  Info posted to this mailing list address won't appear in the tracker database where it is most useful.

Follow-up Comment #1, bug #68091 (group octave):

I forgot to link the line numbers. It's in ls-mat5.cc:260. 

Some questions I have:
1. Can we stream data directly into "octave_uintX" types and avoid using a
local buffer altogether?
2. Can we do a "memcpy" instead of element-wise copy?

In any case, I experimented with a simple patch (attached), directly streaming
raw bytes to destination for int8/uint8 types which don't need a swap. I did
not run into any issues doing that, and at the same time resulted in a
significant performance improvement:

a1 = randi(255, 3000, 3000, "uint8");
save("test.mat", "a1", "-v7", "-nocompression");

% Before patch
tic; load("test.mat"); toc % Elapsed time is 0.285283 seconds.
% After patch
tic; load("test.mat"); toc % Elapsed time is 0.0412259 seconds.



(file #58281)

    _______________________________________________________

Additional Item Attachment:

Name: bug68091.patch                 Size: 4.6KiB
    <https://file.savannah.gnu.org/file/bug68091.patch?file_id=58281>


    AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://savannah.gnu.org/source/savane-2a2ecc185bd672dd377a2efbb667431a4b30acc3.tar.gz


    _______________________________________________________

Reply to this item at:

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

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

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCaZ873QAKCRCqLAuaBUf3
TpOWAQC2EnHSWM71SPw/iDHtn/p2RoB9Np/CuQDoU/3gZIrMfwD8CKAXHQjE7NpC
JZQe2YPrPrWLDnP7ZvTAMIuaRMMX8Ag=
=JxWP
-----END PGP SIGNATURE-----