High CPU usage issue

(Kumar Ankur) #1

Whenever I run my game (2D), the CPU usage increases by 10-12 % and the laptop starts heating up, even though I don’t have much happening in the game as of now, just one character which can run. Whereas, when I run one of the 2D platformer examples of Godot engine, which has a lot more going on, the CPU usage spike is way less, around 3-4%. Can it be something wrong with my code or have others also experienced this?
I am running the game in release mode. In debug mode the spike is way more.

(Marco Alka) #2

Maybe related to this problem?

(Kumar Ankur) #3

@maruru Yes, this might be related. Just to make sure that it is not an issue with my code, I cloned the Evoli repo and ran it. I observed same kind of spike.

(Théo Degioanni) #4

What platform are you running on?

(Kumar Ankur) #5

@Moxinilian I am running on MacOS.
I had a discussion with jaynus and Fusha/termhn on Discord, in the “help” channel, and they also pointed me to the same issue that @maruru has mentioned above. Seems like there is an issue logged for it in the Rayon project as well https://github.com/rayon-rs/rayon/issues/576.

(Kel) #6

Replying to dead/old thread, but because this question is asked often, and I wanted to leave a central place to refer an answer. Essentially there are two parts to this problem but both can be summarized with “threads are spinning to prioritize performance”.

If you’re not familiar with the term, “spinning” is essentially when a thread loops over and over to wait for something, be it a value changing, or a deadline to meet. The first is as you found above. As described in that issue, Rayon is creating a whole bunch of threads in its thread pools (used very importantly in Dispatcher), and those threads are spinning.

The other part is in your FrameRateLimitStrategy. The default strategy for frame limiting is Yield, which will essentially call the “yield” function of your system’s scheduler (SwitchToThread on Windows and sched_yield on Linux, for example) until the remaining time in the frame limit is fulfilled. If there isn’t really anything happening on your system, or in your application for that matter, this will effectively result in the yield being a no-op and your application’s main loop thread will itself spin for a CPU eternity, given a somewhat empty amethyst application with no frame limiting can easily reach 1000’s of frames a second on most systems.

The former appears to likely be possible to remedy although personally speaking I’m not very familiar with rayon internals or the exact details of fixing the problem. The latter, however, is a performance decision. Yes, you could instead use a sleep (or hybrid SleepAndYield) based strategy to improve energy usage, which would be very important for mobile or laptop games, but otherwise it is a big problem for desktop platorms where complex games may end up missing frame deadlines, and find themselves “dropping” frames as other programs shove in their time with the scheduler.

You can find more details on the Rayon issue as linked above here. The documentation for the frame limiter may be found here.