Move tracing::warn call in spawn_try_task to separate function

[dullbananas]

I ran cargo-llvm-lines, and over 1% of the LLVM code comes from calls to spawn_try_task.

Generic functions cause separate LLVM code generation for each unique combination of generic arguments (each implementation of Future for the task parameter in this case). Moving part of the function to a separate non-generic function will reduce the amount of code generation, which can help with compilation speed. https://nnethercote.github.io/perf-book/compile-times.html#llvm-ir

The complexity of the output of the tracing::warn macro can be seen here by selecting "expand macros" under "tools": playground link

Here's the output of cargo-llvm-lines on this commit using dev profile and CARGO_PROFILE_DEV_LTO=fat:
lineslib-lto.zip

I will make similar improvements in Tokio

[phiresky]

Interesting.Change seems ok.

But spawn_try_task is only called with three different arguments, so it should only be monomorphized three times. It seems like that should not make a significant difference? (with the current use of the function)

[Nutomic]

Can you check if this actually makes a noticable difference in build time? cargo build --timings is ideal for this. Make sure to set RUSTC_WRAPPER='' if you use sccache.

[dullbananas]

But spawn_try_task is only called with three different arguments, so it should only be monomorphized three times. It seems like that should not make a significant difference? (with the current use of the function)

cargo-llvm-lines says it's 80 times. This is because it's used by perform and perform_crud in api_routes_http, which are called with different types for Data.

[dullbananas]

Can you check if this actually makes a noticable difference in build time? cargo build --timings is ideal for this. Make sure to set RUSTC_WRAPPER='' if you use sccache.

The amount of LLVM lines reduced by 1.2% (2151193 to 2124873).

I don't want to directly measure the change in build time. It takes a while to build even without cargo clear, and I don't expect to get precise enough results without rebuilding so many times that it would take many hours. And for accurate results, the CPU can't be running anything else during that time.

lineslib-lto-with-change.zip

[Nutomic]

cargo-llvm-lines says it's 80 times. This is because it's used by perform and perform_crud in api_routes_http, which are called with different types for Data.

Im currently getting rid of those traits, see #3596

[Nutomic]

Measured the compile time of this a few times (cherry-picked on top of main), and Im not seeing any improvement.