search

soehrl / tracing-tape

An easy-to-use recorder and viewer for high-performance traces
37 stars 0 forks source link

A question about disabled LTO #24

Open zamazan4ik opened 4 days ago

zamazan4ik commented 4 days ago

Hi!

Recently I found that LTO is disabled for some reason in the Release profile: https://github.com/soehrl/tracing-tape/blob/main/Cargo.toml#L16 . Could you please elaborate a bit on the reason for this? I performed quick local tests (Fedora 41, Rust 1.82): lto = true the binary size from 13 Mib to 9.9 Mib. If you disabled it due to increased build time concerns, I guess we can enable LTO in a dedicated Cargo profile, smth like [profile.heavy-release].

Thank you.

soehrl commented 4 days ago

Hey!

You are right, I disabled it to reduce build times during development. The trace-deck performs poorly for large traces in debug builds, thus it can be useful to use release builds during development. However, It should probably enabled for the default release profile, I am not quite sure why the default release profile has it disabled.

The main reason I commented it out was that in workspaces, you can only define them in the workspace Cargo file and not in individual packages and I don't want to overwrite any default behavior for the library crates (I am also not sure if it works that way, I could not find any information).

I will need to have a look at other binary crates to see how they are doing it. Does this actually cause a problem on your site (aside from binary size/performance) or was this question more out of curiosity?

zamazan4ik commented 3 days ago

You are right, I disabled it to reduce build times during development. The trace-deck performs poorly for large traces in debug builds, thus it can be useful to use release builds during development.

If you want to use Release builds during the development phase but cannot afford using LTO in it due to increased compile times, I can suggest create an additional Cargo profile like [profile.optimized-dev] where you can use Release profile settings but without LTO. In this case, enabling LTO for the Release profile won't harm your development experience.

I am not quite sure why the default release profile has it disabled.

There are some ongoing discussions about different ways of how LTO can be enabled by default in Cargo but there are some blockers (some of them - the increased build time for the Release profile that can affect users). Since Cargo devs don't want to make such a decisions on behalf of all users, for now this decision is left to the applications devs.

The main reason I commented it out was that in workspaces, you can only define them in the workspace Cargo file and not in individual packages and I don't want to overwrite any default behavior for the library crates (I am also not sure if it works that way, I could not find any information).

Cargo will use LTO (and other) settings of the root Cargo file. So if you enable LTO here, and some other person will use tracing-tape as a dependency and will not use LTO for their project - LTO won't be enabled for tracing-tape in their use case.

I will need to have a look at other binary crates to see how they are doing it.

I have some statistics about that since I enabled LTO recently for many Rust binary crates. Almost all of them after my "missing LTO report" enable LTO for the Release profile.

Does this actually cause a problem on your site (aside from binary size/performance) or was this question more out of curiosity?

For the tracing-tape project, it's mostly out of curiosity - I just wondered why the optimization was commented out. However, I like when software by default enables more optimizations for the Release build.