Fix slow desktop controller iteration #11
Conversation
In order to update the list of plugged-in controllers on desktop, the JamepadControllerMonitor iterates through Jamepad's internal list of controllers. This works fine, but in order to get a bound in order to index that list, ControllerManager.getNumControllers() is called. This has performance implications: rather than returning the size of the list, getNumControllers probes each input device to verify it's a controller (rather than some other input device, such as a tablet pen). On Linux, for example, this probing takes the form of an openat(), followed by several ioctl()s and a close(), for each non-contoller input device. This has a very high overhead, going back and forth with the kernel potentially many times each frame, and can tank a game's performance if these peripherals are present. This fix simply uses maxNumControllers as a bounds to index into ControllerManager, which I think is the behavior that was intended anyway. ControllerManager should also probably expose its own bounds to allow consumers to call getControllerIndex() safely.
|
I'm on Debian Bullseye with Linux amd64 5.10.0-6, but I'm not sure how much that matters here. I think the root cause is SDL_IsGameController has to query those devices every time. gdx + lwjgl seems to run it every frame. An overhead of a few ms between kernel and userspace matters a lot, then. I was going from 144+ FPS to 17, so that's a 50ms overhead for each scan. I arrived here after a debugging session that started with me playing Wildermyth and wondering why it was performing so badly: https://steamcommunity.com/app/763890/discussions/0/3077629031367169536 |
|
On Windows SDL's behaviour is sometimes different because the driver stack is completely different (it even differs when using |
|
BTW, Jamepad is not deprecated but maintained under libgdx organisation as well. |
|
I realised that after; I had been looking at https://github.com/williamahartman/Jamepad/ which had the 1.x releases. |
|
This is great and explains a lot about the slowdown! |
In order to update the list of plugged-in controllers on desktop, the
JamepadControllerMonitoriterates through Jamepad's internal list of controllers.This works fine, but in order to get a bound in order to index that list,
ControllerManager.getNumControllers()is called. This has performance implications: rather than returning the size of the list,getNumControllersprobes each input device to verify it's a controller (rather than some other input device, such as a tablet pen).On Linux, for example, this probing takes the form of an openat(), followed by several ioctl()s and a close(), for each non-contoller input device. This has a very high overhead, going back and forth with the kernel potentially many times each frame, and can tank a game's performance if these peripherals are present.
This fix simply uses
maxNumControllersas a bounds to index intoControllerManager, which I think is the behavior that was intended anyway.ControllerManagershould also probably expose its own bounds to allow consumers to callgetControllerIndex()safely.