Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Array serialization #38

Open
funbiscuit opened this issue May 29, 2021 · 1 comment
Open

Array serialization #38

funbiscuit opened this issue May 29, 2021 · 1 comment

Comments

@funbiscuit
Copy link
Contributor

I've seen there was an issue about array serialization and it was "solved" by using lists instead. But it is quite inefficient in both space and speed, especially on embedded devices (while this library seems to be the best for embedded). To give an example, I send data (array of 100000 uint16) over network split to packets of about 512 bytes each. If I use lists, I need about 600 packets, while I can fit into 400 if I use blobs and interpret them on the other side. This is a 50% difference.
In my opinion this library will benefit a lot by adding support of lists of fixed type (and fixed size of each item). Do you think it will be possible? It may be even a small variation to list interpretation where values will be stored one after another and not storing values of different size or type than first item.
Currently I use objects with two keys: t and d. t stores type of each element while d stores blob of an array. And I'm almost fine with it (it doesn't handle endianness but I don't need that). But native support would be a lot better.

@kroggen
Copy link
Collaborator

kroggen commented May 31, 2021

I already thought about this, but currently I have no spare time.

There are many details to decide like storage format, interface, if it should support automatic array increase (push or append instead of just access by position) or only fixed size (informed at creation), if supporting arrays of structs or only basic data types...

It is good to know that you are able to use blobs for this.

Maybe in the future, if there is enough demand for that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants