[bug #68091] Inefficient Integer Data Loading from MAT-Files
Markus Mützel <[email protected]>
| Newsgroups | gmane.comp.gnu.octave.bugs |
|---|---|
| Message-ID | <[email protected]> |
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 #6, bug #68091 (group octave):
jwe agrees that we could skip the temporary buffer in the cases that you
pointed out.
We could take that opportunity to modernize that part of the code by replacing
the preprocessor macro with a more generic C++ template.
E.g., we could create a "mapping" between some `mat5_data_type` enumeration
values and the corresponding implementation data type.
Something along these lines might do that:
template<mat5_data_type T>
struct mat5_type;
template<>
struct mat5_type<mat5_data_type::miINT8> {
using type = int8_t;
};
template<>
struct mat5_type<mat5_data_type::miUINT8> {
using type = uint8_t;
};
[...]
With that, the "mat5_data_type" could be a template parameter of the
`read_mat5_integer_data` template (instead of an argument).
E.g.:
template <typename U, typename T>
void
read_mat5_integer_data (std::istream& is, T *m, octave_idx_type count, bool
swap)
[...]
The template parameter `U` could be "derived" from the enum with something
like `mat5_type<type>::type`.
That might allow using constexpr-if to choose the respective branch on compile
time rather than on runtime.
This would probably also allow to get rid of the `switch (type)` in that
template function entirely.
I haven't tested that idea at all yet. The above snippets might not even
compile. But I hope they still help to get the idea across.
Does that look like a good way forward to you?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68091>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
(application/pgp-signature, 228 B)
-----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCaaFGVQAKCRCqLAuaBUf3 TqluAQCDLzLHOKjGx34X1QvcuMP1uUWG/PMSqFPogMG2pv+4/gD+JZGTf4ez1ymG Pnc1whNwTWOqbzMoj55LYQ5XIHO8cgg= =gpg3 -----END PGP SIGNATURE-----