Big binary size and lots of dependencies

[timvisee]

It looks like notify-rust enlarges the size of binaries by a lot, at least on Linux. I'm seeing a 8MB increase on simple builds when this crate is used. I'm also surprised by the number of dependencies required.

The use of zbus seems to be the culprit.

I wonder if notification handling can be implemented in a different manner to minimize this, both binary size and the number of dependencies. Can any thing be done to achieve this?

Sorry for the possibly vague issue. I am not too familiar with how this is implemented.

[hoodie]

The way that notifications work on freedesktop systems (linux, bsd, etc) is that you send an RPC message to a desktop service provided by Gnome/KDE/etc. This API using DBUS. Doing notifications without zbus would be like "making a REST request" without a HTTP client. This crate has two options for talking to dbus: "zbus" and "dbus (the crate)".

At the moment the later is considered deprecated and I've even received several requests to "finally remove it", however, there are certain tradeoffs. While zbus is the cool new thing and more actively developed, it is true that you have to build the entire dbus-stack yourself and hardlink it as part of your binary -> larger binary.
Alternatively the old implementation links against libdbus-1.so as provided by your OS.

As the d feature is not removed as of now, you might opt for that, it saves you about 3MB on a release build.

Alternately we could investigate whether there is some room to slim down the zbus version of notify-rust by disabling some zbus features that we don't use here.

[timvisee]

That makes sense, thanks for taking the time to reply on this!

I'm having dependency creep in my projects and was looking at the 'biggest' dependencies I was user in an attempt to minimize this. But it seems unavoidable.

[osa1]

As the d feature is not removed as of now, you might opt for that, it saves you about 3MB on a release build.

If it gets removed in the future it would be good to have an alternative (or fork) that keeps it. In tiny, zbus adds an entire async runtime to the binary and adds 90 new dependencies (102 to 192). The final release binary size is 8.2M (4.2 stripped) with zbus and 6.3M (2.8M stripped) with dbus. Statically linked, 8.5M (4.4M stripped) with zbus and 6.8M (3.1M stripped).

[hoodie]

That is curious. My assumption had been that libdbus only makes the binary smaller due to not being linked statically. Now with your numbers the binary with zbus is actually even smaller. Why do you want to add the ability to statically link libdbus then?

[osa1]

Now with your numbers the binary with zbus is actually even smaller

Did you misread my comment maybe? zbus is always larger than dbus.

(My last sentence is missing a part, it should have "... with dbus." at the end.)

Why do you want to add the ability to statically link libdbus then?

Yes, this is why I created #193.

[hoodie]

Oh yes, the with in that sentence threw me off. One more thing: since seem to use tokio in tiny, have you looked into whether you can configure the zbus-tokio-feature? That might save you a few deps. Ultimately I was going to remove the libdbus feature, but exactly comments like these kept me from doing so so far. It's no use to anybody if there are two slightly different versions of this crate just for bin-size reasons.

[osa1]

One more thing: since seem to use tokio in tiny, have you looked into whether you can configure the zbus-tokio-feature

I wasn't aware of this feature. I just tried it, it reduced the release binary size from 8.2M to 8.0M. Looking at the Cargo.lock file, it only removed two dependencies: async-executor and async-fs. Rest of the async-xyz stuff are still in use. (async-io, async-process etc.)