Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Stepping disabled performance fix #11959

Merged
merged 4 commits into from
Feb 19, 2024
Merged

Stepping disabled performance fix #11959

merged 4 commits into from
Feb 19, 2024

Conversation

dmlary
Copy link
Contributor

@dmlary dmlary commented Feb 18, 2024 •
edited
Loading

Objective

Solution

The Option<FixedBitSet> argument added to ScheduleExecutor::run() in #8453 caused a measurable performance impact even when stepping is disabled. This can be seen by the benchmark of running Schedule:run() on an empty schedule in a tight loop (#11932 (comment)).

I was able to get the same performance results as on 0.12.1 by changing the argument
ScheduleExecutor::run() from Option<FixedBitSet> to Option<&FixedBitSet>. The down-side of this change is that Schedule::run() now takes about 6% longer (3.7319 ms vs 3.9855ns) when stepping is enabled

Changelog

  • Change ScheduleExecutor::run() _skipped_systems from Option<FixedBitSet> to Option<&FixedBitSet>
  • Added a few benchmarks to measure Schedule::run() performance with various executors

@dmlary
stepping disabled performance test
dd717c3 
Tryed `&Option<FixedBitSet>` for SystemExecutor::run(), but it didn't
change the performance hit of the argument.

related bevyengine#11932
@dmlary
Trying Option<&FixedBitSet>
7f3f11c 
related bevyengine#11932
@alice-i-cecile alice-i-cecile added the A-ECS Entities, components, systems, and events label Feb 18, 2024
@alice-i-cecile alice-i-cecile added this to the 0.13.1 milestone Feb 18, 2024
@alice-i-cecile alice-i-cecile added the C-Performance A change motivated by improving speed, memory usage or compile times label Feb 18, 2024
@alice-i-cecile
Copy link
Member

Can you split out the removal from the default features? I'd like to ship this in 0.13.1, and that will be a breaking change.

@alice-i-cecile alice-i-cecile added the C-Usability A targeted quality-of-life change that makes Bevy easier to use label Feb 18, 2024
@dmlary
Copy link
Contributor Author

dmlary commented Feb 18, 2024

Can you split out the removal from the default features? I'd like to ship this in 0.13.1, and that will be a breaking change.

Will do

ghost
ghost suggested changes Feb 18, 2024
View reviewed changes
Copy link

@ghost ghost left a comment •
edited by ghost
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM as far as a solution to the regression at hand modulo my other comments.

crates/bevy_ecs/src/schedule/executor/mod.rs Outdated Show resolved Hide resolved
@dmlary dmlary changed the title Stepping disabled performance fix & Remove stepping from default features Stepping disabled performance fix Feb 18, 2024
@ghost ghost added the P-Regression Functionality that used to work but no longer does. Add a test for this! label Feb 18, 2024
@github-actions GitHub Actions
Copy link
Contributor

You added a new feature but didn't update the readme. Please run cargo run -p build-templated-pages -- update features to update it, and commit the file change.

@dmlary dmlary marked this pull request as ready for review February 18, 2024 21:23
ghost
ghost approved these changes Feb 18, 2024
View reviewed changes
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This resolves any concerns I had.

james7132
james7132 approved these changes Feb 18, 2024
View reviewed changes
Copy link
Member

@james7132 james7132 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The performance hit when enabling skipping is unfortunate but likely acceptable given its use as a debugging tool.

@hymm hymm added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Feb 19, 2024
@alice-i-cecile alice-i-cecile added this pull request to the merge queue Feb 19, 2024
Merged via the queue into bevyengine:main with commit 0dccfb5 Feb 19, 2024
24 checks passed
msvbg pushed a commit to msvbg/bevy that referenced this pull request Feb 26, 2024
@dmlary @msvbg
Stepping disabled performance fix (bevyengine#11959)
975689d 
# Objective

* Fixes bevyengine#11932 (performance impact when stepping is disabled)

## Solution

The `Option<FixedBitSet>` argument added to `ScheduleExecutor::run()` in
bevyengine#8453 caused a measurable performance impact even when stepping is
disabled. This can be seen by the benchmark of running `Schedule:run()`
on an empty schedule in a tight loop
(bevyengine#11932 (comment)).

I was able to get the same performance results as on 0.12.1 by changing
the argument
`ScheduleExecutor::run()` from `Option<FixedBitSet>` to
`Option<&FixedBitSet>`. The down-side of this change is that
`Schedule::run()` now takes about 6% longer (3.7319 ms vs 3.9855ns) when
stepping is enabled

---

## Changelog
* Change `ScheduleExecutor::run()` `_skipped_systems` from
`Option<FixedBitSet>` to `Option<&FixedBitSet>`
* Added a few benchmarks to measure `Schedule::run()` performance with
various executors
msvbg pushed a commit to msvbg/bevy that referenced this pull request Feb 26, 2024
@dmlary @msvbg
Stepping disabled performance fix (bevyengine#11959)
d099f04 
# Objective

* Fixes bevyengine#11932 (performance impact when stepping is disabled)

## Solution

The `Option<FixedBitSet>` argument added to `ScheduleExecutor::run()` in
bevyengine#8453 caused a measurable performance impact even when stepping is
disabled. This can be seen by the benchmark of running `Schedule:run()`
on an empty schedule in a tight loop
(bevyengine#11932 (comment)).

I was able to get the same performance results as on 0.12.1 by changing
the argument
`ScheduleExecutor::run()` from `Option<FixedBitSet>` to
`Option<&FixedBitSet>`. The down-side of this change is that
`Schedule::run()` now takes about 6% longer (3.7319 ms vs 3.9855ns) when
stepping is enabled

---

## Changelog
* Change `ScheduleExecutor::run()` `_skipped_systems` from
`Option<FixedBitSet>` to `Option<&FixedBitSet>`
* Added a few benchmarks to measure `Schedule::run()` performance with
various executors
mockersf pushed a commit that referenced this pull request Feb 27, 2024
@dmlary @mockersf
Stepping disabled performance fix (#11959)
5d9c9b8 
# Objective

* Fixes #11932 (performance impact when stepping is disabled)

## Solution

The `Option<FixedBitSet>` argument added to `ScheduleExecutor::run()` in
#8453 caused a measurable performance impact even when stepping is
disabled. This can be seen by the benchmark of running `Schedule:run()`
on an empty schedule in a tight loop
(#11932 (comment)).

I was able to get the same performance results as on 0.12.1 by changing
the argument
`ScheduleExecutor::run()` from `Option<FixedBitSet>` to
`Option<&FixedBitSet>`. The down-side of this change is that
`Schedule::run()` now takes about 6% longer (3.7319 ms vs 3.9855ns) when
stepping is enabled

---

## Changelog
* Change `ScheduleExecutor::run()` `_skipped_systems` from
`Option<FixedBitSet>` to `Option<&FixedBitSet>`
* Added a few benchmarks to measure `Schedule::run()` performance with
various executors
@dmlary dmlary mentioned this pull request May 11, 2024
Closed
NiseVoid pushed a commit to NiseVoid/bevy that referenced this pull request Jul 8, 2024
@dmlary @NiseVoid
Stepping disabled performance fix (bevyengine#11959)
ce22d63 
# Objective

* Fixes bevyengine#11932 (performance impact when stepping is disabled)

## Solution

The `Option<FixedBitSet>` argument added to `ScheduleExecutor::run()` in
bevyengine#8453 caused a measurable performance impact even when stepping is
disabled. This can be seen by the benchmark of running `Schedule:run()`
on an empty schedule in a tight loop
(bevyengine#11932 (comment)).

I was able to get the same performance results as on 0.12.1 by changing
the argument
`ScheduleExecutor::run()` from `Option<FixedBitSet>` to
`Option<&FixedBitSet>`. The down-side of this change is that
`Schedule::run()` now takes about 6% longer (3.7319 ms vs 3.9855ns) when
stepping is enabled

---

## Changelog
* Change `ScheduleExecutor::run()` `_skipped_systems` from
`Option<FixedBitSet>` to `Option<&FixedBitSet>`
* Added a few benchmarks to measure `Schedule::run()` performance with
various executors
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@alice-i-cecile alice-i-cecile alice-i-cecile approved these changes

@james7132 james7132 james7132 approved these changes

Assignees
No one assigned
Labels
A-ECS Entities, components, systems, and events C-Performance A change motivated by improving speed, memory usage or compile times C-Usability A targeted quality-of-life change that makes Bevy easier to use P-Regression Functionality that used to work but no longer does. Add a test for this! S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Milestone
0.13.1
Development

Successfully merging this pull request may close these issues.

Noticeable schedules running overhead
4 participants
@dmlary @alice-i-cecile @james7132 @hymm