Hi,
Probably a minor issue, but I've noticed some functions in fred have pretty big stack frames, which sometimes leads to stack overflow in our tests.
For example, when using fred 8.0.1 compiled with these features ["custom-reconnect-errors", "dns", "serde-json", "metrics", "enable-rustls", "partial-tracing", "sha-1", "serde-json"] fn fred::router::commands::process_command takes up ~400 KB of stack space in debug build (~100 KB in release build). There are more functions in the ballpark of 100KB-200KB.
Just wondering if there is some low hanging fruit there to be able to reduce stack usage. It's most likely due to large argument/return types (and Future return types can get large pretty fast due to rust-lang/rust#59087).
Clippy can help keep sizes in check with lints like clippy::large_types_passed_by_value, clippy::large_stack_frames, clippy::large_futures.
Hi,
Probably a minor issue, but I've noticed some functions in
fredhave pretty big stack frames, which sometimes leads to stack overflow in our tests.For example, when using fred
8.0.1compiled with these features["custom-reconnect-errors", "dns", "serde-json", "metrics", "enable-rustls", "partial-tracing", "sha-1", "serde-json"]fn fred::router::commands::process_commandtakes up ~400 KB of stack space in debug build (~100 KB in release build). There are more functions in the ballpark of 100KB-200KB.Just wondering if there is some low hanging fruit there to be able to reduce stack usage. It's most likely due to large argument/return types (and Future return types can get large pretty fast due to rust-lang/rust#59087).
Clippy can help keep sizes in check with lints like
clippy::large_types_passed_by_value,clippy::large_stack_frames,clippy::large_futures.