an empty Ebitengine application uses 6-8% CPU

[hajimehoshi]

Ebitengine Version

4bb016f

Operating System

• Windows
• macOS
• Linux
• FreeBSD
• OpenBSD
• Android
• iOS
• Nintendo Switch
• PlayStation 5
• Xbox
• Web Browsers

Go Version (go version)

go version go1.24.3 darwin/arm64

What steps will reproduce the problem?

1. Run this program:

package main

import (
	"log"
	"net/http"
	_ "net/http/pprof"

	"github.com/hajimehoshi/ebiten/v2"
)

type Game struct{}

func (self *Game) Layout(w, h int) (int, int) {
	return w, h
}

func (self *Game) Update() error {
	return nil
}

func (self *Game) Draw(*ebiten.Image) {}

func main() {
	go func() {
		log.Println(http.ListenAndServe("localhost:6060", nil))
	}()

	game := &Game{}
	ebiten.SetScreenClearedEveryFrame(false)
	if err := ebiten.RunGame(game); err != nil {
		log.Fatal(err)
	}
}

2. See the CPU usage at Activity Monitor
3. Run

What is the expected result?

CPU usages should be much low like 1%

What happens instead?

CPU usages were around 6-8%

Anything else you feel useful to add?

go tool pprof -http=:8081 "http://localhost:6060/debug/pprof/profile?seconds=5" shows that pthread_cond is called many times

[tjpalmer]

This also affects linux and windows. It's currently one of my biggest concerns with Ebitengine, so I'm glad to see it's on the radar!

[hajimehoshi]

Apparently Thread.Call and UserInterface.currentMonitor are more expensive than I expected.

A) takes about 2.5% CPU on my machine

diff --git a/internal/ui/ui_glfw.go b/internal/ui/ui_glfw.go
index 34d91a911..5ac108d72 100644
--- a/internal/ui/ui_glfw.go
+++ b/internal/ui/ui_glfw.go
@@ -1472,6 +1472,8 @@ func (u *UserInterface) updateGame() error {
        if unfocused {
                t1 = time.Now()
        }
+       time.Sleep(time.Second / 60)
+       return nil
 
        var outsideWidth, outsideHeight float64
        var deviceScaleFactor float64

B) takes about 2.8% CPU on my machine

diff --git a/internal/ui/ui_glfw.go b/internal/ui/ui_glfw.go
index 34d91a911..d3168d032 100644
--- a/internal/ui/ui_glfw.go
+++ b/internal/ui/ui_glfw.go
@@ -1477,6 +1477,7 @@ func (u *UserInterface) updateGame() error {
        var deviceScaleFactor float64
        var err error
        if u.mainThread.Call(func() {
+               return
                outsideWidth, outsideHeight, err = u.update()
                if err != nil {
                        return
@@ -1489,6 +1490,8 @@ func (u *UserInterface) updateGame() error {
        }); err != nil {
                return err
        }
+       time.Sleep(time.Second / 60)
+       return nil
 
        if err := u.context.updateFrame(u.graphicsDriver, outsideWidth, outsideHeight, deviceScaleFactor, u); err != nil {
                return err

C) takes about 3.5-4% CPU on my machine

diff --git a/internal/ui/ui_glfw.go b/internal/ui/ui_glfw.go
index 34d91a911..20b8bf82c 100644
--- a/internal/ui/ui_glfw.go
+++ b/internal/ui/ui_glfw.go
@@ -1477,18 +1477,21 @@ func (u *UserInterface) updateGame() error {
        var deviceScaleFactor float64
        var err error
        if u.mainThread.Call(func() {
-               outsideWidth, outsideHeight, err = u.update()
+               /*outsideWidth, outsideHeight, err = u.update()
                if err != nil {
                        return
-               }
+               }*/
                m, err := u.currentMonitor()
                if err != nil {
                        return
                }
-               deviceScaleFactor = m.DeviceScaleFactor()
+               _ = m
+               //deviceScaleFactor = m.DeviceScaleFactor()
        }); err != nil {
                return err
        }
+       time.Sleep(time.Second / 60)
+       return nil
 
        if err := u.context.updateFrame(u.graphicsDriver, outsideWidth, outsideHeight, deviceScaleFactor, u); err != nil {
                return err

[hajimehoshi]

The next target is *UserInterface.update, which invokes many GLFW functions.

[hajimehoshi]

The next target is glfw.PollEvents, but I don't think there is an easy solution.

[tjpalmer]

The next target is glfw.PollEvents, but I don't think there is an easy solution.

Thanks so much for the effort on this! One option could be to toggle WaitEvents vs PollEvents and calculate some effective number of passed ticks. Could make it the responsibility of apps/games activating wait mode to cope with the differences.

[hajimehoshi]

WaitEvents stops forever until the next event comes so this doesn't work well with the current Ebitengine. WaitEventsTimeout is almost the same as PollEvents in terms of performance.

[hajimehoshi]

Instead of PollEvents, we might be able to change the architecture by waiting for an event and send it via a channel. I don't think this improves CPU usages, but this would improve responsiveness. See also #1704 (comment)