v0.6-dev - binary size increase

[michaelherger]

I see that the binaries for 0.6-dev have increased in size considerably compared to the previous 0.6. A release build on macOS/arm64 would now be up to 7.2MB from 4.3MB. Is this to be expected? Or did I miss something?

[photovoltex]

Could you include your compile command? Or is it without any adjustments?

[roderickvd]

You can strip debug info but I don't think that even happens by default in release profile:

https://doc.rust-lang.org/cargo/reference/profiles.html#strip
https://doc.rust-lang.org/cargo/reference/profiles.html#release

[photovoltex]

And here are my final finds on the topic https://docs.google.com/spreadsheets/d/1eSYGozN89wzfH2lV9l6tfL6nHr-iprYG24ORtQa50eM.

The binary seem to have increased in size ~0.9MB when optimized with

[profile.release]
strip = true
lto = true
codegen-units = 1
opt-level = 'z'
panic = 'abort'

I think this might be alright, as we added flate2 and protobuf_json_mapping and the changes where still quite big. I might also be wrong as I never optimized rust binaries before.

The last thing we could still investigate is on how much the dependencies and the code itself changed the size. If I find some time, I will take a look at it again as the topic seems quite interesting hehe.

[roderickvd]

When using tokio I think it's best to keep panic as unwind, to let it catch_unwind in various places to clean up.

[michaelherger]

@michaelherger I just did a quick search for lto and I didn't found anything that would speak against the use of the flag? Do you have any reference to that recommendation that you mentioned? Personally I don't see any harm in decreasing the size of the binary. And as long as the logger still works (and we have logging at the correct positions) it should be fine in my opinion.

Maybe I confused it with stripping the binary. In any case I haven't seen much of an issue in the several years I've been using it.

That said, I believe this is not the point about the topic I've raised. What I was seeing is that the file size increased considerably, all given the same parameters and build options.

Hopefully I'll find some time over the Holidays to play with 67d3195...2ecb8f0. Is this part of a PR I could check out?

[photovoltex]

The slice contains the first four commits of the dealer rework. I still have local copies of the branch so I can easily checkout the revisions. I will push the branch later so that you can investigate yourself (https://github.com/photovoltex/librespot/tree/merged/integrate-dealer). I also think the branch is not complete, but as the first four commits already make such a big difference it's maybe already enough to find the root cause.