batocera-tuning

Batocera Tuning

Performance: why the frontend or a game runs slow, and how to fix it. Assumes the connection pattern and batocera.conf model from batocera-ops. The theme throughout: diagnose the machine state before blaming config, themes, or gamelists. Most "it got slow" reports are a throttle or a leak, not the thing the user suspects.

Diagnostic order for "the frontend is slow"

Work down this list; each step is one command and rules out a whole class:

1. CPU governor. A frontend that is laggy from cold boot and stays laggy through a reboot is almost always the CPU stuck in powersave:

   SSHB "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor"
   

   If it says powersave despite system.cpu.governor=performance, see the governor fix below. This is step 1 because it's the most common cause and the cheapest check.
2. ES event hooks. Lag that gets progressively worse as you navigate, and is cured only by an ES restart, points at a slow/leaky ES event hook. ES runs every executable in its scripts dirs on menu events — a system-selected hook fires on every carousel tile change and can add permanent per-frame cost. Audit /userdata/system/scripts/ and /userdata/system/configs/emulationstation/scripts/. Because hooks are global (not theme-scoped), this masquerades as a "theme-independent ES bug" — the tell is that it accumulates per tile visited. See below.
3. Texture cache. Lag that's fine at first and worsens with a large media set, with revisits staying fast, can be ES texture-cache eviction thrash. Raising MaxVRAM in es_settings.cfg (e.g. to 1024) can help, but measure — on some builds the GPU floor and MaxVRAM make no difference and the real cause is #1 or #2.
4. GPU clock floor. Only chase this after 1–3. On a vsync-paced frontend the GPU often won't upclock on its own, but pinning a higher floor frequently makes no measurable difference — A/B it before persisting anything.