Ebiten: High CPU usage on context switching in input

[mortenson]

I've noticed that CPU usage for any of the Ebiten examples seems quite high, is there a reason for this or is this not a concern?

I'm on Linux, testing CPU usage using top, and running examples using go run (running binaries gives similar results). I'm on a fairly high-spec laptop, running an Intel® Core™ i7-1065G7 CPU with 16GB or memory. All Ebiten examples range between 50-75% CPU usage.

Any ideas?

[hajimehoshi]

Hi,

Which version of Ebiten are you using?

[mortenson]

@hajimehoshi For testing the examples I'm using master, and for my games I'm using v1.11.8.

[hajimehoshi]

Looks like there are no significant differences between master and 1.11.8. I think CPU usage might be an issue, but there are no low-hanging fruits to fix the performance.

I'll keep this open for a while, but I've not come up with action items. Let me investigate.

[pwiecz]

In my experience using inpututil in a simple game was a most significant source of high CPU usage.
It seems that calling IsKeyPressed for every possible key sixty times per second has very high CPU overhead in Go runtime (thread scheduling + channel communication).
Maybe having an API that would get state of all the keys, mouse buttons etc. in a single call would improve this case.

[hajimehoshi]

Thank you for pointing this out!

Maybe having an API that would get state of all the keys, mouse buttons etc. in a single call would improve this case.

This sounds good, but this means that Ebiten requires a new API. I'd like to avoid adding a new API for inpututil.

Instead, IsKeyPressed's implementation can be a mutex + a slice. This should be much more efficient than the current channels.

[hajimehoshi]

OK I've removed thread switching. @pwiecz, Could you try the latest commit?

[pwiecz]

There's a significant improvement.
The CPU usage went down from ~48% to ~25%.

Thanks!

[hajimehoshi]

Thanks!

If @mortenson is satisfied, I'd like to close this issue, and let's create another issue when we find another.

[mortenson]

Looking good to me! Feel free to close and thanks for diving in.

[sheerun]

tbh 25% cpu for rendering practically nothing is also high usage

[hajimehoshi]

I see, but an appropriate CPU usage depends on its context.

[windo]

I've been looking into this, too. My update/draw code finishes in less than 1ms, but the glfw machinery with inputs and PBO updates, Thread.Call and the like (I'm not sure what exactly, I've just run into these) is using up some 25% of CPU, which sounds very high. On my low-end laptop there are also some significant pauses where updates stop for ~100ms or so - but IDK yet if that's related to the high CPU usage or just masked by it.

Anyway, I don't suppose there are any ideas I could try out to make Thread.Call more efficient? Maybe to run critical sections wholly on the main thread, rather than doing it section by section?

[hajimehoshi]

Right, and actually Thread.Call is one of the most significant CPU consumer. See the discussion at https://github.com/hajimehoshi/ebiten/issues/1367

So, we should remove the calls of Thread.Call as much as possible.

[windo]

Thanks for the link, I'll follow that issue!

Also, I've sort of located the source of my UI stutters, it's somehow caused by SwapBuffers starting to take longer and longer. I'll file another issue for that.