Is that possible to optimize binary output?

[alexzaru]

I have successfully compiled and executed the demo client project with TLS on Rust stable version 1.74. When adjusting dependencies such as replacing pretty_env_logger with env_logger (excluding couple morefeatures) and using a minimal subset of Tokio's features, the resulting binary size is still substantial at 2.4 MB for a build after stripping debug symbols.

My target environment is an embedded Linux platform running FreeRTOS, with approximately 18MB of total flash space and around 6-8MB available. The current binary size eating almost 40% of available space, considering the intended simplicity of the MQTT program, akin to a "Hello, world!" equivalent. In the context of Rust binaries, it might not be excessively large, but for my specific use case, it poses challenges. For comparison, the existing MQTT system, written in C using mosquitto, has a total size around 125kB based on pluging.

Reducing the binary size is crucial for me as it necessitates writing four other parts in C if I choose to implement the MQTT components in Rust. While cargo bloat assists in identifying contributing packages, pinpointing specific ones remains challenging. The primary culprits are std (as expected), rustls, and ring, with Tokio following closely. I think there are possibilities to address that.

[alexzaru]

I propose the following solutions:

1. Feature-gating additional components, if feasible.
2. Allowing compatibility with non-Tokio runtimes, such as async-std, smol, etc, or adapting to event loops based on file-descriptors, like Calloop.
3. Generalizing runtime to be also a pluging, assuming current universal approach

Not sure how hard to implement it but I might help if I understand correct approach

[sigrlami]

This is not a typical use case; generalization of runtime is feasible but extremely complex and time-consuming task.

I'll check over the weekend if there are ways to optimize it including your suggestions.