cpu usage

[coolit]

e.g. In the "button" example, sometimes the cpu usage is about 10-20% in release mode, which is relatively high.
Is there any plan for future improvement? Thanks.
edit: I used win10, Intel 2.40GHz.

[joseluis]

CPU usage is between 300% and 400% for me with the simplest examples (button, sprite...)

EDIT: Using Mint 20 on Linux 5.4 on Intel i7-8705G and dual video card Radeon RX Vega M GL + HD Graphics 630

[martin-fl]

I confirm this.
On a i7-7700HQ CPU @ 2.80GHz × 8 and iGPU, htop outputs indicates that e.g the breakout example takes ~40% on all cores

[skreborn]

@coolit @joseluis @martin-fl What operating systems, hardware, and render backend do you all use?

[martin-fl]

@skreborn
I'm using PopOS 20.04 with Linux 5.4 on a Intel® Core™ i7-7700HQ CPU @ 2.80GHz × 8 and Mesa Intel® HD Graphics 630 (KBL GT2). The render backend is Vulkan I suppose.

[skreborn]

I have anywhere between 50% and 70% usage on Windows 10 with an Intel® Core™ i7-9750H CPU @ 2.60GHz × 12 and an NVIDIA GeForce RTX 2080 Max-Q for button.

It's worth noting that release mode reduces that to slightly above 30%.

[MGlolenstine]

It's not just low-end hardware


EDIT:
Even in release mode, the CPU usage is at 60%.
Apparently the logic updates every "frame" and it's not set, but faster the CPU, more the frames.

We should lock logic frames to a sane number like 90 or 180.

[martin-fl]

It's worth noting that release mode reduces that to slightly above 30%.

Compiling in release mode does in fact reduce CPU usage to ~10% on the button and breakout example on my computer. Still a bit high for a single button though.

[Timidger]

Release mode had the sprite example running at around 30% for me, based on htop. Bit disappointing such a simple example isn't performant, but the library looks like a great start so I feel silly even making the complaint. I figure this will be fixed quickly.

here is a flamegraph, hopefully it's helpful

[cart]

I expect there to be a ton of low hanging fruit when it comes to optimization. So far the focus has been on api surface and building solid foundations. For example, right now Bevy is way more hash-ey per-frame than I would like it to be. We can fix most of the CPU getting eaten there by using the new "change detection" features in Bevy ECS.

On top of that, I think some persistent CPU usage is expected, as we (currently) use rayon under the hood and other projects have encountered similar behavior. I think the most important metric bevy can optimize is frame_time (which you can measure by adding the FrameTimeDiagnosticsPlugin and PrintDiagnosticsPlugin to your app).

This is the sort of issue that will never fully be resolved. There will always optimization work to do.

I am inclined to close this issue (and reference it whenever a new one comes up). Feel free to open issues for specific cases where you have isolated slow parts of Bevy.

(also i wont close this for a small period of time. feel free to respond here with rationale if you think leaving this open is better)

[aclysma]

This is a problem with rayon. The more cores you have, the more CPU you burn. My 3950x pins the CPU at 100% in the window_settings example. I've seen this behavior on several projects that use rayon.

rayon-rs/rayon#642

[aclysma]

As a workaround for anyone having an unpleasant time with this, you can use the environment variable RAYON_NUM_THREADS to limit the number of threads. I would recommend anyone with more than 8 cores set it to something <=8.

Just to be clear, this isn't "bevy is using a lot of CPU" it's "rayon doesn't properly idle threads that have no work to do". A 32 logical core CPU will pin at 100%, but when forced to use 8 logical cores, will run at about 13% utilization (despite that being 25% of the cores). That is still higher than it ought to be. I don't think bevy's examples generate enough workload to justify saturating multiple cores.

[tbillington]

Would something like Unity's Application.targetFrameRate be related to this issue?

[multun]

that's probably fixed by rayon-rs/rayon#746