-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Merged by Bors] - bevy_utils: remove hardcoded log level limit #4580
Conversation
Going to benchmark this; if there are no measurable regressions I think this is good to go. |
I'm getting a stable 32 FPS on many_sprites / 30 on many_cubes in release mode either way. I don't think this is a measurable performance regression. |
bors r+ |
# Objective - Debug logs are useful in release builds, but `tracing` logs are hard-capped (`release_max_level_info`) at the `info` level by `bevy_utils`. ## Solution - This PR simply removes the limit in `bevy_utils` with no further actions. - If any out-of-the box performance regressions arise, the steps to enable this `tracing` feature should be documented in a user guide in the future. This PR closes #4069 and closes #1206. ## Alternatives considered - Instruct the user to build with `debug-assertions` enabled: this is just a workaround, as it obviously enables all `debug-assertions` that affect more than logging itself. - Re-exporting the feature from `tracing` and enabling it by default: I believe it just adds complexity and confusion, the `tracing` feature can also be re-enabled with one line in userland. --- ## Changelog ### Fixed - Log level is not hard capped at `info` for release builds anymore. ## Migration Guide - Maximum log levels for release builds is not enforced by Bevy anymore, to omit "debug" and "trace" level logs entirely from release builds, `tracing` must be added as a dependency with its `release_max_level_info` feature enabled in `Cargo.toml`. (`tracing = { version = "0.1", features = ["release_max_level_info"] }`)
I've added a migration notice, although I don't think it is something that requires migration, and documentation would better fit in a user guide (either the official one, or the cheatbook). The migration docs between versions will become irrelevant in the future versions. |
Agreed; that's why I opened #4586. This is just out of an abundance of caution; I've seen users get frustrated about perceived performance regressions even if they aren't measurable. Thanks! |
bors r+ |
Already running a review |
# Objective - Debug logs are useful in release builds, but `tracing` logs are hard-capped (`release_max_level_info`) at the `info` level by `bevy_utils`. ## Solution - This PR simply removes the limit in `bevy_utils` with no further actions. - If any out-of-the box performance regressions arise, the steps to enable this `tracing` feature should be documented in a user guide in the future. This PR closes bevyengine#4069 and closes bevyengine#1206. ## Alternatives considered - Instruct the user to build with `debug-assertions` enabled: this is just a workaround, as it obviously enables all `debug-assertions` that affect more than logging itself. - Re-exporting the feature from `tracing` and enabling it by default: I believe it just adds complexity and confusion, the `tracing` feature can also be re-enabled with one line in userland. --- ## Changelog ### Fixed - Log level is not hard capped at `info` for release builds anymore. ## Migration Guide - Maximum log levels for release builds is not enforced by Bevy anymore, to omit "debug" and "trace" level logs entirely from release builds, `tracing` must be added as a dependency with its `release_max_level_info` feature enabled in `Cargo.toml`. (`tracing = { version = "0.1", features = ["release_max_level_info"] }`)
# Objective - Debug logs are useful in release builds, but `tracing` logs are hard-capped (`release_max_level_info`) at the `info` level by `bevy_utils`. ## Solution - This PR simply removes the limit in `bevy_utils` with no further actions. - If any out-of-the box performance regressions arise, the steps to enable this `tracing` feature should be documented in a user guide in the future. This PR closes bevyengine#4069 and closes bevyengine#1206. ## Alternatives considered - Instruct the user to build with `debug-assertions` enabled: this is just a workaround, as it obviously enables all `debug-assertions` that affect more than logging itself. - Re-exporting the feature from `tracing` and enabling it by default: I believe it just adds complexity and confusion, the `tracing` feature can also be re-enabled with one line in userland. --- ## Changelog ### Fixed - Log level is not hard capped at `info` for release builds anymore. ## Migration Guide - Maximum log levels for release builds is not enforced by Bevy anymore, to omit "debug" and "trace" level logs entirely from release builds, `tracing` must be added as a dependency with its `release_max_level_info` feature enabled in `Cargo.toml`. (`tracing = { version = "0.1", features = ["release_max_level_info"] }`)
Objective
tracing
logs are hard-capped (release_max_level_info
) at theinfo
level bybevy_utils
.Solution
bevy_utils
with no further actions.tracing
feature should be documented in a user guide in the future.This PR closes #4069 and closes #1206.
Alternatives considered
debug-assertions
enabled: this is just a workaround, as it obviously enables alldebug-assertions
that affect more than logging itself.tracing
and enabling it by default: I believe it just adds complexity and confusion, thetracing
feature can also be re-enabled with one line in userland.Changelog
Fixed
info
for release builds anymore.Migration Guide
tracing
must be added as a dependency with itsrelease_max_level_info
feature enabled inCargo.toml
. (tracing = { version = "0.1", features = ["release_max_level_info"] }
)