bevy/examples/diagnostics/custom_diagnostic.rs

31 lines
1 KiB
Rust
Raw Permalink Normal View History

//! This example illustrates how to create a custom diagnostic.
2020-05-04 21:14:49 +00:00
use bevy::{
diagnostic::{
Diagnostic, DiagnosticPath, Diagnostics, LogDiagnosticsPlugin, RegisterDiagnostic,
},
2020-05-04 21:14:49 +00:00
prelude::*,
};
fn main() {
App::new()
.add_plugins((
DefaultPlugins,
// The "print diagnostics" plugin is optional.
// It just visualizes our diagnostics in the console.
LogDiagnosticsPlugin::default(),
))
Allow systems using Diagnostics to run in parallel (#8677) # Objective I was trying to add some `Diagnostics` to have a better break down of performance but I noticed that the current implementation uses a `ResMut` which forces the functions to all run sequentially whereas before they could run in parallel. This created too great a performance penalty to be usable. ## Solution This PR reworks how the diagnostics work with a couple of breaking changes. The idea is to change how `Diagnostics` works by changing it to a `SystemParam`. This allows us to hold a `Deferred` buffer of measurements that can be applied later, avoiding the need for multiple mutable references to the hashmap. This means we can run systems that write diagnostic measurements in parallel. Firstly, we rename the old `Diagnostics` to `DiagnosticsStore`. This clears up the original name for the new interface while allowing us to preserve more closely the original API. Then we create a new `Diagnostics` struct which implements `SystemParam` and contains a deferred `SystemBuffer`. This can be used very similar to the old `Diagnostics` for writing new measurements. ```rust fn system(diagnostics: ResMut<Diagnostics>) { diagnostics.new_measurement(ID, || 10.0)} // changes to fn system(mut diagnostics: Diagnostics) { diagnostics.new_measurement(ID, || 10.0)} ``` For reading the diagnostics, the user needs to change from `Diagnostics` to `DiagnosticsStore` but otherwise the function calls are the same. Finally, we add a new method to the `App` for registering diagnostics. This replaces the old method of creating a startup system and adding it manually. Testing it, this PR does indeed allow Diagnostic systems to be run in parallel. ## Changelog - Change `Diagnostics` to implement `SystemParam` which allows diagnostic systems to run in parallel. ## Migration Guide - Register `Diagnostic`'s using the new `app.register_diagnostic(Diagnostic::new(DIAGNOSTIC_ID, "diagnostic_name", 10));` - In systems for writing new measurements, change `mut diagnostics: ResMut<Diagnostics>` to `mut diagnostics: Diagnostics` to allow the systems to run in parallel. - In systems for reading measurements, change `diagnostics: Res<Diagnostics>` to `diagnostics: Res<DiagnosticsStore>`.
2023-06-05 20:51:22 +00:00
// Diagnostics must be initialized before measurements can be added.
.register_diagnostic(Diagnostic::new(SYSTEM_ITERATION_COUNT).with_suffix(" iterations"))
.add_systems(Update, my_system)
2020-05-04 21:14:49 +00:00
.run();
}
// All diagnostics should have a unique DiagnosticPath.
const SYSTEM_ITERATION_COUNT: DiagnosticPath = DiagnosticPath::const_new("system_iteration_count");
2020-05-04 21:14:49 +00:00
Allow systems using Diagnostics to run in parallel (#8677) # Objective I was trying to add some `Diagnostics` to have a better break down of performance but I noticed that the current implementation uses a `ResMut` which forces the functions to all run sequentially whereas before they could run in parallel. This created too great a performance penalty to be usable. ## Solution This PR reworks how the diagnostics work with a couple of breaking changes. The idea is to change how `Diagnostics` works by changing it to a `SystemParam`. This allows us to hold a `Deferred` buffer of measurements that can be applied later, avoiding the need for multiple mutable references to the hashmap. This means we can run systems that write diagnostic measurements in parallel. Firstly, we rename the old `Diagnostics` to `DiagnosticsStore`. This clears up the original name for the new interface while allowing us to preserve more closely the original API. Then we create a new `Diagnostics` struct which implements `SystemParam` and contains a deferred `SystemBuffer`. This can be used very similar to the old `Diagnostics` for writing new measurements. ```rust fn system(diagnostics: ResMut<Diagnostics>) { diagnostics.new_measurement(ID, || 10.0)} // changes to fn system(mut diagnostics: Diagnostics) { diagnostics.new_measurement(ID, || 10.0)} ``` For reading the diagnostics, the user needs to change from `Diagnostics` to `DiagnosticsStore` but otherwise the function calls are the same. Finally, we add a new method to the `App` for registering diagnostics. This replaces the old method of creating a startup system and adding it manually. Testing it, this PR does indeed allow Diagnostic systems to be run in parallel. ## Changelog - Change `Diagnostics` to implement `SystemParam` which allows diagnostic systems to run in parallel. ## Migration Guide - Register `Diagnostic`'s using the new `app.register_diagnostic(Diagnostic::new(DIAGNOSTIC_ID, "diagnostic_name", 10));` - In systems for writing new measurements, change `mut diagnostics: ResMut<Diagnostics>` to `mut diagnostics: Diagnostics` to allow the systems to run in parallel. - In systems for reading measurements, change `diagnostics: Res<Diagnostics>` to `diagnostics: Res<DiagnosticsStore>`.
2023-06-05 20:51:22 +00:00
fn my_system(mut diagnostics: Diagnostics) {
// Add a measurement of 10.0 for our diagnostic each time this system runs.
diagnostics.add_measurement(&SYSTEM_ITERATION_COUNT, || 10.0);
2020-05-04 21:14:49 +00:00
}