Reduce number of dependencies of zvariant

[notgull]

See #1649

zvariant brings in a number of dependencies that can probably be reduced. From the list, in order of relative difficulty:

• The code using endi can be implemented using the standard library fairly easily.
• The code using winnow can likely be implemented with it, using a parser built using only standard library utilities.
• zvariant_derive et al can be made into optional features. This would allow removing the proc-macro dependencies from zvariant and zvariant_utils.
• serde can be made optional. However, this requires us to have an alternative API for marshalling than serde.
• proc-macro-crate can be removed from zvariant-derive as per Drop proc-macro-crate dependency #1365
• There is a reality where zvariant is no-std or even no-alloc.

[zeenix]

zvariant brings in a number of dependencies that can probably be reduced.

While I support this goal in general, I think we should be systematic about this and establish a more concrete criteria than just "oh, this crate has a bunch of deps". I have been down this road before (see #304). I guess some of that can only be established while making the changes but we need to measure the impact of each removed dependency on build times and see if it's actually wort the trouble to remove the dep.

• The code using endi can be implemented using the standard library fairly easily.

endi is a no-dep no-std super slim crate. Moving the code into this crate, might make the build (slightly) slower, not faster given that cargo can parallelize builds across crates.

As the creator of endi, I could have just kept it in zbus from the get go but I think it makes sense to split generic code into separate crates for better usage. Anyway, try that and see if it reduces the build times.

• [ ] The code using winnow can likely be implemented with it, using a parser built using only standard library utilities.

winnow makes the parser code easier to read and maintain. Moreover, it doesn't drag other deps and cargo can easily parallelize its build, so I'm very sceptical of the benefits to cost, ratio.

Also to take into consideration that this is quite a widely used crate so even if removing this dependency greatly reduces the build-time, using apps are not very likely to benefit from that unless everyone abandons this crate.

• [ ] zvariant_derive et al can be made into optional features. This would allow removing the proc-macro dependencies from zvariant and zvariant_utils.

Sure.

• [ ] serde can be made optional. However, this requires us to have an alternative API for marshalling than serde.

This is even more widely used crate than winnow and any useful app is almost guaranteed to use it either directly or indirectly. So given the amount of work needed, I am 99.9999% certain removing this dependency is not at all worth it.

• [ ] proc-macro-crate can be removed from zvariant-derive as per Drop proc-macro-crate dependency #1365

👍

[zeenix]

So in the eframe tree at least, if zbus stops using serde then serde can be removed from the tree entirely.

Sure but:

• eframe is a library and apps using it, are very likely to be depending on serde either directly or indirectly, due to its ubiquitous-ness.
• zbus doesn't just exist for eframe :) and even if it did, this will still need concrete rationale (mainly in terms of significant impact on build times and/or binary size).

[notgull]

Whoops, accidentally'd my earlier post. I think there is value in a D-Bus serialization layer without serde, but there are definitely higher-priority dependencies that can be axed first.

[zeenix]

Whoops, accidentally'd my earlier post. I think there is value in a D-Bus serialization layer without serde, but there are definitely higher-priority dependencies that can be axed first.

Np, I have it in my inbox. Let me paste the parts I want to reply to:

Making it extra clear that the below text represents my personal opinion and does NOT represent the stances of my employer.

My main issue with serde is the demonstrable supply chain risk of using it, especially given the author's ties to American surveillance companies. In this case I would argue that the ubiquitous-ness of serde is a bad thing, and that zbus could bolster itself as a leader in software supply chain security by distancing itself from serde.

What needs to be kept in mind is that the very liberal licensing of serde allows for forking of the project under the leadership of more trustworthy folks so if you are serious about emancipating the Rust community from serde, I'd suggest doing that and then convincing projects to use this fork instead. It will also be a lot less work, both (especially) in terms of coding involved and convincing people (since you'd be basically selling a drop-in replacement).

[Ablu]

• [ ] serde can be made optional. However, this requires us to have an alternative API for marshalling than serde.

This is even more widely used crate than winnow and any useful app is almost guaranteed to use it either directly or indirectly. So given the amount of work needed, I am 99.9999% certain removing this dependency is not at all worth it.

One problem that I observe is that the additional generic layers that zbus adds on top of serde force a lot of code duplication.

So I am seeing a lot of:

[self:          536 bytes inclusive:        14672 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<std[c2fa75df6f512e45]::io::cursor::Cursor<&mut alloc[1c36ba8c62004634]::vec::Vec<u8>>>>::serialize_struct_element::<zvariant[17b915e2f3c80ce9]::fd::Fd> (@244b80)
[self:          536 bytes inclusive:        20156 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<std[c2fa75df6f512e45]::io::cursor::Cursor<&mut alloc[1c36ba8c62004634]::vec::Vec<u8>>>>::serialize_struct_element::<zvariant_utils[8fe57fc0177a6ef1]::signature::Signature> (@247c30)
[self:          536 bytes inclusive:        18856 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<std[c2fa75df6f512e45]::io::cursor::Cursor<&mut alloc[1c36ba8c62004634]::vec::Vec<u8>>>>::serialize_struct_element::<zvariant[17b915e2f3c80ce9]::str::Str> (@247e48)
[self:          536 bytes inclusive:        12560 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<zvariant[17b915e2f3c80ce9]::ser::NullWriteSeek>>::serialize_struct_element::<u16> (@250c40)
[self:          536 bytes inclusive:        14040 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<std[c2fa75df6f512e45]::io::cursor::Cursor<&mut alloc[1c36ba8c62004634]::vec::Vec<u8>>>>::serialize_struct_element::<u32> (@2486c0)
[self:          536 bytes inclusive:        14028 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<std[c2fa75df6f512e45]::io::cursor::Cursor<&mut alloc[1c36ba8c62004634]::vec::Vec<u8>>>>::serialize_struct_element::<i16> (@248af0)
[self:          536 bytes inclusive:        14032 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<std[c2fa75df6f512e45]::io::cursor::Cursor<&mut alloc[1c36ba8c62004634]::vec::Vec<u8>>>>::serialize_struct_element::<u8> (@248f20)
[self:          536 bytes inclusive:        14028 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<std[c2fa75df6f512e45]::io::cursor::Cursor<&mut alloc[1c36ba8c62004634]::vec::Vec<u8>>>>::serialize_struct_element::<u16> (@2488d8)
[self:          536 bytes inclusive:        12864 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<zvariant[17b915e2f3c80ce9]::ser::NullWriteSeek>>::serialize_struct_element::<u8> (@251288)
[self:          536 bytes inclusive:        18808 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<std[c2fa75df6f512e45]::io::cursor::Cursor<&mut alloc[1c36ba8c62004634]::vec::Vec<u8>>>>::serialize_struct_element::<zvariant[17b915e2f3c80ce9]::object_path::ObjectPath> (@247a18)
[self:          536 bytes inclusive:        19424 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<zvariant[17b915e2f3c80ce9]::ser::NullWriteSeek>>::serialize_struct_element::<zvariant_utils[8fe57fc0177a6ef1]::signature::Signature> (@24c97c)
[self:          536 bytes inclusive:        12864 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<zvariant[17b915e2f3c80ce9]::ser::NullWriteSeek>>::serialize_struct_element::<bool> (@251070)
[self:          536 bytes inclusive:        18028 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<zvariant[17b915e2f3c80ce9]::ser::NullWriteSeek>>::serialize_struct_element::<zvariant[17b915e2f3c80ce9]::str::Str> (@2501b0)
[self:          536 bytes inclusive:        12560 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<zvariant[17b915e2f3c80ce9]::ser::NullWriteSeek>>::serialize_struct_element::<i16> (@250e58)
[self:          536 bytes inclusive:        17980 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<zvariant[17b915e2f3c80ce9]::ser::NullWriteSeek>>::serialize_struct_element::<zvariant[17b915e2f3c80ce9]::object_path::ObjectPath> (@24ff98)
[self:          536 bytes inclusive:        14040 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<std[c2fa75df6f512e45]::io::cursor::Cursor<&mut alloc[1c36ba8c62004634]::vec::Vec<u8>>>>::serialize_struct_element::<bool> (@248d08)
[self:          536 bytes inclusive:        14052 bytes]  -><zvariant[17b915e2f3c80ce9]::dbus::ser::StructSerializer<zvariant[17b915e2f3c80ce9]::ser::NullWriteSeek>>::serialize_struct_element::<zvariant[17b915e2f3c80ce9]::fd::Fd> (@24d960)

(this just cites a random example, there are a bunch of other calls that get stamped out many times like this. Note: the "inclusive" column may be a bit misleading, it counts the total size of other symbols that are reachable from the symbol in the callgraph, but there may be duplicates under that.)

It feels like in a lot of cases dynamic dispatch would be sufficient and would save a lot of code overhead. Unfortunately serde makes that hard as it does not support dynamic dispatch in it's core traits.

As an example:

Simply removing the NullWriteSeek trait and making those code paths go through a Cursor<&mut Vec> saves ~50kB in my testing (which is 1% of my final binary size!). If there would be a way to get rid of the various serialize_struct_element instantiations then that would allow cutting a multiple of that.

EDIT: moved to #304 (comment)

[zeenix]

@Ablu Thanks so much for you input. It's quite useful but I think it's more relevant to #304 than this issue. Care moving it there? I can do it for you, if you like?

[Ablu]

@Ablu Thanks so much for you input. It's quite useful but I think it's more relevant to #304 than this issue. Care moving it there? I can do it for you, if you like?

moved!