Array unmarshalling constructs a list before populating vector about haskell-dbus

[IvanMalison]

It seems to me that we should use arrays that are definitely unboxed (so that we can load them by doing a simple memcpy), and probably storable (in case people want access to the underlying ptrs) in case people want to pass pointers to C functions through FFI.

We can add instances to IsValue for Data.Vector so that it is still possible to easily unmarshal to a normal boxed haskell vector if the user prefers that.

This approach would avoid tons of extra unmarshalling in cases where performance may be a concern.

[rblaze]

Is there a use case for DBus where performance is a concern? I honestly don't know, my understanding is DBus used for semantically rich, but low-data interactions.

Said that, deserializing data directly to vector instead of intermediate list looks like an obvious change.

[IvanMalison]

@rblaze DBus is used to communicate things like full menus which will contain several images. Image data can be large enough that it doesnt make sense to store it in lists, and doing so can significantly slow things down, so yes, I think there are use cases where performance is a concern.

[rblaze]

Yes, deserializing without intermediate lists is good in any case. I just wonder if it worth playing with memcpy-like constructs, sacrificing readability and safety.

[rblaze]

I took another look at this. To significantly improve performance with large byte arrays I'll need to change exposed types and marshaling code.

In this particular place, the performance hit isn't that significant: it only copies pointers to the boxed values, not values themselves. But I'll update it to use direct vector creation anyway.

[rblaze]

On the closer look, nothing I can do there. Marshaled DBus arrays do not provide item count, the only way to know how many elements are there is to read them until data are exhausted. And vectors need to know item count in advance.

🤦‍♂️