Significant slowdown when listing titles in many homebrew after FW 20.x.x

  • Thread starter Thread starter Willsito_GG
  • Start date Start date
  • Views Views 5,178
  • Replies Replies 39
  • Likes Likes 1

Willsito_GG

Well-Known Member
Member
Joined
Dec 31, 2017
Messages
345
Reaction score
192
Trophies
0
XP
2,192
Country
Spain
Hello GBATemp Team,

First of all, thank you very much again for your support and help in any adventure that we might have within this console scene 🙏🏻

I am opening this post after searching for this information, in order to follow up with you about the following concern I have with my recently updated and tested v1 Nintendo Switch. My current setup is FW 20.3.0, Atmosphère 1.9.3, SD card formatted as FAT32 with everything updated, tested and working perfectly, except for what I describe below.

To make sure it was not caused by a bad configuration or faulty sysmodule, I have tested with all sysmodules removed from SD\atmosphere\contents, and also with unmodified configuration files in SD\atmosphere\config, SD\config and others. The issue persists in all cases.

New observation: one interesting thing is that, when going to the native Program Management Menu, under Settings → Data Management → Software, the list of installed apps there seems to load maybe even faster than before (in addition, back on 19.0.1 it often crashed when I entered this menu, and now it doesn’t). This makes me think that perhaps the key is to adapt homebrew apps to the new way the ns service works. 🙏🏻

The problems are the following:

  • In the Switch main menu, application icons also take noticeably longer to appear, and navigation feels slightly less responsive. Here is a comparison for icon loading between fw19 and fw20 by TotalJustice: https://gbatemp.net/threads/jksv-save-manager-for-switch.516186/post-10651801

  • There are some homebrew that require listing all installed titles or applications take significantly longer to load, suggesting the slowdown might be related to changes in how FW 20.x.x handles title listing via ns services:
    • For example, in the case of JKSV, this "Loading..." window takes more than a minute to disappear and for the save data menus to appear. On FW 19.x.x and earlier, this used to take only a few seconds:
      1754823373947.png
    • Or DBI, when selected Browse Installed Applications, in the "Retrievving applications info..." loading window, screen for over a minute before the main list appears. On FW 19.x.x and earlier, this used to take only a few seconds:
      1754823437593.png
The main thing is that Impeeza mentioned this in a post, but I could not find any other place discussing it, so I decided to open this thread to ask for your impressions and ideas, and above all, to know whether this is being taken into account in order to fix this unexpected behavior.

Thanks in advance for your time and for looking into this.

Best regards,

Willsito

--------------------------------------------------------------------------------------------------------------------------------
This analysis was conducted by me together with ChatGPT 5, based on multiple tests and code inspection.

Summary of findings:
  • Observed behavior:
    • Since FW 20.x.x (post-19.0.1), homebrew (JKSV, DBI…) that rely on listing all installed titles take significantly longer to complete operations like “Loading…”, “Retrieving applications info” or “Clean up orphaned files”.
    • In the Switch main menu, application icons also take noticeably longer to appear, and navigation feels slightly less responsive.
  • Technical cause:
    • Since FW 20.x.x (post-19.0.1), homebrew (JKSV, DBI…) that rely on listing all installed titles take significantly longer to complete operations like “Loading…”, “Retrieving applications info” or “Clean up orphaned files”.
    • These tools call Nintendo Switch’s ns service via libnx (nsListApplicationRecord plus control-data requests) to enumerate installed titles.
    • FW 20.x.x likely added extra validation or processing in ns, increasing overhead for large title libraries.
    • The slowdown is at the Horizon OS service level, not caused by Atmosphère or direct database access.
  • Atmosphère’s role:
    • Atmosphère can MITM services for compatibility, but currently has no public patches to optimize ns performance.
    • Optimization would require intercepting and caching ns responses, which is outside Atmosphère’s usual scope.
  • Conclusion:
    • The slowdown originates in FW 20.x.x’s ns service, affecting all homebrew (JKSV, DBI…) that enumerate titles through it plus, in the Switch main menu, application icons also take noticeably longer to appear, and navigation feels slightly less responsive.
    • Improvements can only come from firmware changes or optimizations in the affected homebrew.
    • Homebrew should reduce initial bulk calls to ns, use pagination, lazy-load metadata/icons, and implement persistent caching.
    • Atmosphère could theoretically mitigate the issue via a custom patch, but this is outside its usual scope.

So yeah, it will be up to either Atmosphère or each homebrew app to adapt to the new ns service behavior. Let’s hope their developers have the time, motivation, and enthusiasm to fix or adapt this, or at least give it a try!
Best regards,

Willsito
 
Last edited by Willsito_GG,
  • Like
Reactions: Ragolay
I have seen a few users mention issues like this with 2.0.x.x, especially the recent latest 20.3.0, which is why I stayed on 19.0.1 firmware. The problem is you cannot open a issue thread like this on the official Atmosphere Github, as I already seen two get ignored and users shutdown in their place, due to them being so anal about piracy, if something is mentioned like DBI.

It could be the internal changes N did and the lesser memory allocation (wild guess) but I have been looking for a solution to this problem before I ever want to update again.
Post automatically merged:

Lol, just realised now, it was one of your posts you made on the Atmosphere Github that got closed.
 
Last edited by retrofan_k,
It's a firmware issue... Not related with atmosphere.
Bug? or because of the changes N did to the firmware or a intentional way of trying to disable homebrew apps by making it awkward and cumbersome to now use? It's hard to say to be honest but hope a solution or fix can be done.
 
  • Like
Reactions: Willsito_GG
This analysis was conducted by me together with ChatGPT 5, based on multiple tests and code inspection.

Summary of findings:
  • Observed behavior:
    • Since FW 20.x.x (post-19.0.1), homebrew (JKSV, DBI…) that rely on listing all installed titles take significantly longer to complete operations like “Loading…”, “Retrieving applications info” or “Clean up orphaned files”.
    • In the Switch main menu, application icons also take noticeably longer to appear, and navigation feels slightly less responsive.
  • Technical cause:
    • Since FW 20.x.x (post-19.0.1), homebrew (JKSV, DBI…) that rely on listing all installed titles take significantly longer to complete operations like “Loading…”, “Retrieving applications info” or “Clean up orphaned files”.
    • These tools call Nintendo Switch’s ns service via libnx (nsListApplicationRecord plus control-data requests) to enumerate installed titles.
    • FW 20.x.x likely added extra validation or processing in ns, increasing overhead for large title libraries.
    • The slowdown is at the Horizon OS service level, not caused by Atmosphère or direct database access.
  • Atmosphère’s role:
    • Atmosphère can MITM services for compatibility, but currently has no public patches to optimize ns performance.
    • Optimization would require intercepting and caching ns responses, which is outside Atmosphère’s usual scope.
  • Conclusion:
    • The slowdown originates in FW 20.x.x’s ns service, affecting all homebrew (JKSV, DBI…) that enumerate titles through it plus, in the Switch main menu, application icons also take noticeably longer to appear, and navigation feels slightly less responsive.
    • Improvements can only come from firmware changes or optimizations in the affected homebrew.
    • Homebrew should reduce initial bulk calls to ns, use pagination, lazy-load metadata/icons, and implement persistent caching.
    • Atmosphère could theoretically mitigate the issue via a custom patch, but this is outside its usual scope.

So yeah, it will be up to either Atmosphère or each homebrew app to adapt to the new ns service behavior. Let’s hope their developers have the time, motivation, and enthusiasm to fix or adapt this, or at least give it a try!

New observation: one interesting thing is that, when going to the native Program Management Menu, under Settings → Data Management → Software, the list of installed apps there seems to load maybe even faster than before (in addition, back on 19.0.1 it often crashed when I entered this menu, and now it doesn’t). This makes me think that perhaps the key is to adapt homebrew apps to the new way the ns service works. 🙏🏻

Best regards,

Willsito
 
Last edited by Willsito_GG,
  • Like
Reactions: retrofan_k
JKSV's rewrite code has a caching system like I did for JKSM on 3DS way back in the day to get around this. I tried implementing in the master branch's code but decided it was worth the headache and effort. There's rewrite code NRO's in my thread for JKSV if it really bothers you that much. Adding anything to the master branch is a nightmare.
 
JKSV's rewrite code has a caching system like I did for JKSM on 3DS way back in the day to get around this. I tried implementing in the master branch's code but decided it was worth the headache and effort. There's rewrite code NRO's in my thread for JKSV if it really bothers you that much. Adding anything to the master branch is a nightmare.

Hello JK_!

Thank you very much for stopping by!

Thanks a lot for the suggestion and for taking the time to explain it.

I don’t really have experience with that kind of programming, so it’s not something I can jump into right now… Maybe someday in the future.

That said, I think the problem might not be fully solved just by adding a caching layer, since it would still need to refresh on every access and, for that, it would have to call the same slow service again, which could bring us back to the same situation.

Anyway, I’ll keep investigating, thank you very much 🙏🏻

Best regards

Willsito
 
Im on firmware 18.1.0 and i only ran into this issue when i updated atmosphere and sigpatches i did not update the firmware at all.
 
  • Like
Reactions: Willsito_GG
i noticed an SSL cert issue on TF (won't go away even with a ntp sync through switchtime or dbi wonder if thats related a little (on 20.0.3)
 
Hello Team!

Last night I was running some tests and came across the following findings:
  1. When running SYSNAND with Atmosphere (FW 20.3.0, Atmosphère 1.9.3), JKSV loads the games very quickly, same as it did before with FW 19.0.1 on EMUNAND.
  2. The key differences between my SYSNAND and EMUNAND setups (both launched with Atmosphere) are:
    • On EMUNAND I have a few more native Switch titles, but many additional forwarders to RetroArch games created with https://nsp-forwarder.n8.io/.
    • On SYSNAND, the SysPatch sysmodule is not active.
Conclusion from these tests:
  • FW 20.3.0 itself does not cause a slowdown per se.
  • The real slowdown seems to be triggered by the presence of “unexpected” titles (e.g., RetroArch forwarders) and how they are accessed during title listing.
  • If accessing these forwarders requires SysPatch sysmodule and Atmosphere, then, there is hope that one or both of these components could be updated to make listing operations more efficient and take the "high old speed" back.

Any comments or additional insights are very welcome!

Thanks in advance,

Best regards

Willsito
 
Last edited by Willsito_GG,
I have also been experiencing slowdowns after updating to firmware 20.x.x, at first I thought it might be the SD card, so I connected it to the PC and checked for errors, but that didn't help. Everything feels slower, games take a little longer to boot, the main menu feels a bit less responsive, and yeah DBI takes an extremely long time when loading the list of installed titles.
 
  • Like
Reactions: Willsito_GG
Issue comes from the fact that Nintendo foolproofed a case where game will come with icon taking more than 128kB (that's the limit imposed by NS services) and bigger than 256x256 because of NS2, though instead of first checking if that icon even needs downsizing/downscaling they put every single one through that process, on top of that also using purely cpu code instead of NVJPG. That's the source of issue.

I am avoiding long booting time of FPSLocker overlay by loading game titles in separate thread (because game titles come with icons in one struct) and using mutex when accessing vector storing titles.

Function that is used since 20.0.0 for every JPEG
https://switchbrew.org/wiki/Jpegdec_services#ShrinkJpegEx
That's also where known 2206-1015 error came from that was fixed in 20.0.1
https://switchbrew.org/wiki/20.0.1#ns


So you were investigating something that was known the very first week it was introduced. :D Nice way of wasting time.


If I could bet on something, it probably can be replaced by other function that was added to the same session service with 20.0.0+ (they added 11 new commands, all of them using async to not wait for full output to continue), but nobody put time into figuring out what they are doing and how they work. That's also why sys-tweak doesn't work - until all of those are researched, it cannot be patched to work with 20.0.0+

https://switchbrew.org/wiki/NS_services#IReadOnlyApplicationControlDataInterface
 
Last edited by masagrator,
I noticed that games i installed recently boot normal and fast but games i installed not so recent take forever to boot i wonder if reinstalling the games will make them boot faster i will try.
So i just reinstalled a game that was slow booting (Metroid Prime) and it boots fast again so i guess reinstalling your games can fix the issue at least for me it works im on firmware 18.1.0 and im using sysnand cfw.
 
Last edited by worm28,

Site & Scene News

Popular threads in this forum