search

dbus2 / zbus-old

Rust D-Bus crate.
https://gitlab.freedesktop.org/dbus/zbus
Other
49 stars 13 forks source link

Syncronous Only Implementation #334

Closed zeenix closed 1 year ago

zeenix commented 1 year ago

In GitLab by @TTWNO on Mar 11, 2023, 19:23

I've had a few discussions with the team at AccessKit, and they are looking at reducing their binary size. Currently, adding support for accessibility in the Bevy game engine, for example, adds around 1MB to the binary. They want this closer to the 100-300K used for a11y in Windows and MacOS. Currently, they use my implementation of AT-SPI in the atspi crate, which depends on zbus.

Our options are the following:

  1. Try to use the dbus crate, which has C bindings to libdbus.
  2. Get blocking-only support from zbus so that they don't need to compile and include a runtime along with their binaries.

I'd also like to see support for a fully-blocking feature flag to reduce dependencies in environments that don't require it. Is this something that would be considered? I looked through previous issues and I couldn't see any mention of it being suggested before.

Thanks for all your work so far on this library!

zeenix commented 1 year ago

I've had a few discussions with the team at AccessKit, and they are looking at reducing their binary size. Currently, adding support for accessibility in the Bevy game engine, for example, adds around 1MB to the binary. They want this closer to the 100-300K used for a11y in Windows and MacOS. Currently, they use my implementation of AT-SPI in the atspi crate, which depends on zbus.

Our options are the following:

  1. Try to use the dbus crate, which has C bindings to libdbus.

I already participated in that discussion and believe that I provided my view on that option in detail. :smile:

  1. Get blocking-only support from zbus so that they don't need to compile and include a runtime along with their binaries.

What runtime? If you're talking about smol-rs crates deps, that is unlikely to be the reason from the binary size being larger than usual. At least it's not the main reason. You can disable almost all of those deps through disabling default features and you'll still get a similar size. They are very tiny libs with very few deps.

Since this is all based on cargo bloat output, you'll find that this command, when run w/o --crates option, tells you exactly which functions are the biggest culprits according to it. You'll see that async runtime have not much to do with it.

I'd also like to see support for a fully-blocking feature flag to reduce dependencies in environments that don't require it. Is this something that would be considered?

As said, we already have feature flags to disable most of the deps, you're currently just then limited to tokio (very selective features of it, though). Our API is primarily async so I believe this will be a huge task and is unlikely to be possible w/o big API breaks.

Given that and the fact that this is very unlikely to help much with the binary size issue (if at all), I'd be very reluctant here. I'd suggest looking into finishing my efforts to split the generics-heavy API and then using the new non-generic API everywhere in zbus and zbus_macros. I was actually hoping to look into that myself soon.

Thanks for all your work so far on this library!

You're welcome.

We already have #304 where we are tracking the binary size so let's continue discussions there.

zeenix commented 1 year ago

In GitLab by @TTWNO on Mar 12, 2023, 05:14

Apoligies for bringing up this issue again. I somehow missed that conversion and had done this without searching in the upstream repo.

Again, thanks! This library is very useful!

zeenix commented 1 year ago

Apoligies for bringing up this issue again. I somehow missed that conversion and had done this without searching in the upstream repo.

No worries. Not your fault you were not given all the relevant information. :)