Retroarch: [3DS] Slow core startup from loading/inventorying core files: Workaround identified, seeking fix

[sunrisepi]

Description

When loading a core, it takes about 25 seconds. It then takes another 25 seconds to load a game.

Expected behavior

Cores and games should load in <5 seconds each, based on my experience with RetroArch on Raspberry Pi.

Actual behavior

Cores and games take too long to load.

Steps to reproduce the bug

Start RetroArch, select a core to load. Wait ~25 seconds. Then select a game to load. Wait ~25 seconds.

Bisect Results

I just started using RetroArch today on 3DS, so don't know how long this issue has been present.

Version/Commit

Version 1.8.9, from https://buildbot.libretro.com/stable/1.8.9/nintendo/3ds/RetroArch_cia.7z

Environment information

Using Nintendo CDS with CFW

How I worked around issue

Described in my post here: https://github.com/libretro/RetroArch/issues/10355#issuecomment-647044049. To summarize:

• I only wanted to use nestopia and didn't need the other cores.
• I made a new directory /retroarch/cores/cores_notused and moved all cores in /retroarch/cores except nestopia_libretro.cia to /retroarch/cores/cores_notused
• Now when I start a core, it completes in about 4 seconds. Games load in a bit less than 4 seconds.

Other Comments

It would be great if the way RetroArch is designed/implemented on 3DS could be updated/modified, so that this issue doesn't exist for new users. I really like RetroArch; it's fantastic! This additional change would really improve the experience for 3DS users. Thank you! 😁

[twinaphex]

@jdgleaver You have some input here?

[jdgleaver]

This is very difficult to deal with...

There are two main problems here:

• We don't have access to the online core updater on 3DS, so the RetroArch download bundle has to contain the full set of cores. RetroArch is designed such that a core is considered 'installed' if the core file exists. 3DS is pretty much the only platform where an 'existing' core isn't necessarily installed - but even here, an existing core file means the core is available for use, since it will be installed automatically (if required) when launching content. Conclusion: We can't change how RetroArch handles the presence of core files.

• In order to actually use a core, we need to read its corresponding info file (this tells us, among other things, the type of content it can load). These are teeny tiny files, and on every other platform it takes a few milliseconds to read them - but 3DS is again a special case. It has the most appallingly slow microsd random access/transfer speeds I have ever seen anywhere - it's barely functional. So something that takes no time at all on every other platform takes forever on 3DS.

How can we deal with this? Well, the most obvious solution is the one you've already found: reduce the number of 'installed' cores, and the 3DS has less work to do. I always only copy over the cores I have any interest in (that's 11 of them), and startup times when testing are ~3-4 seconds (quite acceptable!)

The alternative solution is to change how info files are loaded... justinweiss had some suggestions in his issue report:

I filed this mostly for if there's a way to not load these until they're needed

Well, we do only load them when needed, so that's a strike

or cache the .info after the first time

No can do. The 3DS uses a static build, which means core loading is done via a fork. So that's a complete 'quit the program and start over' - which in turn means that any cached core info from before the fork is lost. We have to load everything again...

or load them in the background

Nope - we need then when we need them, and we need them from the get-go.

or batch them up into one larger file

This is a possibility...

The current method of loading individual info files is pretty lousy from a performance perspective (the config file format is hugely inefficient when it comes to parsing operations, and multiple file open/close operations are bad in general, even if they are fast on other platforms). A single file would improve this, but:

• We can't just bundle the info together and read it all in one go: the info files combined are ~1MB, and that's too much memory to allocate on the weaker platforms, and too much data to parse in general - especially when most of it wouldn't be needed (i.e. it would end up making things worse)

• So we'd need a searchable database file. This has the problems of being (a) difficult to maintain (since the database would have to be rebuilt any time anyone modified a source info file) and (b) difficult to implement - probably too much work for anyone to bother with, not when the tangible benefits would only be felt on one platform...

Finally, although I expect this to be the case, it's difficult to tell if it really is the file access that's causing the extreme slowness, or something else (since it's impossible to profile anything on 3DS). e.g. I know that reading 50 runtime info files takes 4-5 seconds on 3DS, which is horribly slow - but nowhere near the 25 seconds that you are seeing. So is it the info file parsing code, which is very heavy on the string manipulation and memory allocation? But then again, the main retroarch.cfg file is parsed in exactly the same way, and that's ~100kb of text, and takes no time to read at all. My point here is that any changes will involve difficult work, and we won't really know if it makes a difference until after it's all finished...

So I'm not really sure how to approach this...

One thing that might be worth trying is converting the info files to JSON format - this would be quite non-invasive code-wise, and using the JSON parser would massively reduce the amount of required memory allocation and string search operations. This should benefit all platforms to some degree. I'm busy with other RetroArch stuff at the moment, but I'll try to have a play with this when I find time...

[sunrisepi]

Thanks @twinaphex and @jdgleaver . Really appreciate all the input.

Perhaps as an immediate fix, we could add some info to the documentation, alerting 3DS users to this problem and how to work around it? It's as simple as moving unused cores from /retroarch/cores directory to another, like /retroarch/cores/cores_notused.

The documentation I used to install is here: https://docs.libretro.com/guides/install-3ds2ds/. Adding a few notes there would be helpful to new users. Is that something someone on the RetroArch team would like to add, or would you like me to suggest an update to the documentation? ☺️

[i30817]

Just to avoid the obvious, are you sure that the streams opened in the 3ds are buffered?

[jdgleaver]

@sunrisepi An update to the documentation sounds like a great idea. If you'd like to do this yourself, we'd all appreciate it :)

The source file is here: https://github.com/libretro/docs/blob/master/docs/guides/install-3ds2ds.md

Do you know how to fork a repo and make a PR? Or would you like to learn? It can be nice to be recorded as a contributor :)

If you want to do that, and need any help, I can point you to a guide. Alternatively, you can post an updated install-3ds2ds.md and I can make the PR for you.

@i30817 Yeah, in this case the whole file is loaded into RAM before we start parsing it, so it's not a buffering issue. The 3DS just has terrible disk performance (it's absolutely shocking - Nintendo really cut corners there...)

[sunrisepi]

@jdgleaver That would be great if you could explain/point me to documentation on how I could "fork a repo and make a PR". I would love to contribute some updates to the documentation! Thank you. 😃

[jdgleaver]

@sunrisepi Okay, that's great to hear! Contributors are always welcome :)

The best git guides I ever read are these ones here (if you're starting from scratch, you'll want to go through all of them - they're quite short):

https://blog.scottlowe.org/2015/01/14/non-programmer-git-intro/
https://blog.scottlowe.org/2015/01/26/using-git-with-github/
https://blog.scottlowe.org/2015/01/27/using-fork-branch-git-workflow/

As for the docs repo itself, once you've checked out your local copy you'll want to edit docs/guides/install-3ds2ds.md, and then you can test your changes by building the html files. To do this on the command line, it's:

> cd path/to/docs
> mkdocs build

Note that you'll need a working mkdocs install: https://www.mkdocs.org/

Those are the basics - You'll probably have more questions as you get started, so please ask if you need any help!

[sunrisepi]

@jdgleaver Thanks! I will read these and advise if I have questions. 😅

[sunrisepi]

@jdgleaver I've submitted the pull request: https://github.com/libretro/docs/pull/520

Took about 3 hours for me to get this done. Some notes:

• Had issues getting Python PIP working (I'm using Windows), and then there was a complaint about a missing module when I tried running mkdocs serve: It said cannot find module 'materialx.emoji' (No module named 'materialx')
• Some digging led me to https://pypi.org/project/mkdocs-material-extensions/. Installed that missing content with pip install mkdocs-material-extensions and then I was on my way...
• Verified mkdocs build completed OK and the content looked good via mkdocs serve so submitted the pull request.

It probably took about 30 minutes to review the docs you shared (thanks! very helpful), another 90 minutes to get the environment all set up on my computer (install git, install python, install pip, install mkdocs), then about an hour to get the docs updated & issue the pull request.

Hope folks like the documentation! Thanks. 😆 ☺️

[jdgleaver]

@sunrisepi That's great! The new documentation is perfect :)

We do really appreciate the effort you put into this - thanks very much!

[sunrisepi]

@jdgleaver Thanks a bunch for all the insight & your help getting this done! Closing this out; have a good one. 👍