![]() 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. So I'm not really sure how to approach this. 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 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. 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. 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.įinally, 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). 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. 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). Nope - we need then when we need them, and we need them from the get-go. 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. The 3DS uses a static build, which means core loading is done via a fork. Well, we do only load them when needed, so that's a strike I filed this mostly for if there's a way to not load these until they're needed justinweiss had some suggestions in his issue report: The alternative solution is to change how info files are loaded. 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!) 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. So something that takes no time at all on every other platform takes forever on 3DS. It has the most appallingly slow microsd random access/transfer speeds I have ever seen anywhere - it's barely functional. ![]() 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. 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). Conclusion: We can't change how RetroArch handles the presence of core files. 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. RetroArch is designed such that a core is considered 'installed' if the core file exists. 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. I really like RetroArch it's fantastic! This additional change would really improve the experience for 3DS users. 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.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |