Retroachievements on RetroArch for 3DS causes massive stutters

[shigutso]

First and foremost consider this:

• Only RetroArch bugs should be filed here. Not core bugs or game bugs
• This is not a forum or a help section, this is strictly developer oriented

Description

I'm using retroarch 1.19.1 on my New 3DS and there is a performance degradation when I enable retroachievements, even for gameboy games.
I followed the documentation and removed all cores not being used and that improved loading times but retroachievements are still causing a big impact on performance. Seems to be caching something for the first few minutes and then stabilizes, but if an achievement is going to trigger, there's a lot of stutters.

The 3DS is not a powerful device, but maybe resources are being overused for processing retroachievements.

Expected behavior

No stutters

Actual behavior

Lots of stutters

Steps to reproduce the bug

1. Install RetroArch on 3DS
2. Add games
3. Enable retroachievements
4. Start a game compatible with retroachievements
5. Massive stutters will be present or game will freeze for several minutes
6. (if retroachievements are disabled, game does not freeze or stutter)

Bisect Results

N/A

Version/Commit

You can find this information under Information/System Information

• RetroArch: 1.19.1

Environment information

• OS: New Nintendo 3DS
• Compiler: N/A

[Jamiras]

Seems to be caching something for the first few minutes and then stabilizes

This is the badges being downloaded: #16470.

but if an achievement is going to trigger, there's a lot of stutters.

Closest I could find for this is: #13139, which sounds like it's possibly no longer an issue.

[shigutso]

Indeed it seems to be mostly related to badges being downloaded.
If we can get an option to skip that and keep text-only, would fix the issue.
Or perhaps the download code could be optimized for the 3DS so it won't overwhelm the CPU

However, I found a particular case with a game
If you play Dr. Mario for Game Boy, before starting a run you can select the speed of the game
Every time you change the speed, there's a brief notification from retroachievements, causing mini-stutters
So I don't know if downloading images is the only cause, maybe displaying the images is also having a impact on 3DS CPU usage

[i30817]

I keep banging on this drum, but everything to do with the notification widget while emulation is running, especially if there is animation going on and the hardware RA is running is not multicore or has threaded tasks disabled is a recipe for 'microstutters'.

This is because of how the widgets display, they have a api to draw something at the start, the end, and a task chosen number for a task time in between. It just turns out that to run, these need to interrupt emulation without threaded tasks and I doubt it's very nice for the emulator thread even with them.

This is inevitable but it would be nice to have a alternate tasks setting that turns off animations for the more common usecases (sliders, fading in and out etc), and just keeps the start and end.

My first suspicion of the pathological slowdown this design causes was comparing upstream dolphin savestate times to RetroArch, then checking the code and doing a little bpf program to count the number of iterations of the code interrupting the savestate write to draw the slider. It was very pathological and didn't vary by savestate sizes, it was always n bytes (chosen at compile time, more bytes for weaker host platforms) in all cases so larger savestate emulated consoles were always much slower than upstream because they were doing many many more iterations (as opposed to say, increasing the slider by 1% every iteration). Add to that that modern PCs are made to write files all at once for maximum speed, not interrupt the write every few bytes, and it's no wonder dolphin is much much faster writing savestates, since they just display the final 'savestate name saved'.

I would feel no surprise if something similar was going on with networking to download a file or fading in\out a badge, not necessarily the image.