citro2d performance issues after devkitARM/ctrulib update

[TheGag96]

(This is mostly a repost of this issue.)

I recently updated all of devkitARM's packages through dkp-pacman, and after recompiling my homebrew with everything, I found that my call to C2D_SpriteSheetLoad from citro2d now takes an obscene amount of time (about 1.5 seconds on o3ds) for the spritesheet I was trying to load, where it took like 1/10th of the time before.

This can even be seen this in the gpusprites example - try compiling this edit. On my o3ds, it clocks in at 486.67 milliseconds to load just the spritesheet. It seems like size of the sheet doesn't really matter, exactly, but instead the number of sprites in the sheet.

Citro3d's recent changes aren't the culprit, and citro2d itself didn't change very much recently (and nothing related to spritesheet loading), so my only guess is that recent ctrulib changes had something to do with it. My only other guess is something in devkitPro's move to GCC 10.1, but I'm not sure. I'd like to try recompiling an older ctrulib, but I can't even compile it for some reason:

Code: Select all

In file included from /opt/devkitpro/devkitARM/arm-none-eabi/include/c++/10.1.0/stdlib.h:36,
                 from /home/grayson/Packages/ctrulib/libctru/source/allocator/mem_pool.h:3,
                 from /home/grayson/Packages/ctrulib/libctru/source/allocator/vram.cpp:8:
/opt/devkitpro/devkitARM/arm-none-eabi/include/c++/10.1.0/cstdlib:232:11: error: 'strtold' has not been declared in '::'
  232 |   using ::strtold;
      |           ^~~~~~~
/opt/devkitpro/devkitARM/arm-none-eabi/include/c++/10.1.0/cstdlib:252:22: error: 'strtold' has not been declared in '__gnu_cxx'
  252 |   using ::__gnu_cxx::strtold;
      |                      ^~~~~~~

Really looks like my installation is broken somehow, but I'm not sure what to do about it. Any ideas as to what this might be? Thanks!

[WinterMute]

As it turns out a file I/O optimisation we did in devkitARM was broken under very specific circumstances (see https://github.com/devkitPro/newlib/issues/16) and the fix slowed it down slightly. For what it's worth testing with our optimisation completely reverted led to a load time of 839.02ms so there's definitely a big impact there. Clearly also working as intended is better than faster but not working as intended.

I tested allowing a bigger buffer for the file I/O in C2D_SpriteSheetLoad which brought the load time down to 76ms so I commited and released that just now. Running pacman -Syu should get you the new library & shorter loading times.

If your toolchain installation is broken then running (sudo) (dkp-)pacman -S 3ds-dev should sort it out.

We don't support old toolchains, old libraries or compilation issues related to them. Ideally if you have a problem then you should report a bug before trying to fix it yourself. We can and often will fix issues fairly quickly when they're reported and we have a reasonable testcase to work with. Thanks for showing us this one and allowing us the opportunity to fix it.

[TheGag96]

As it turns out a file I/O optimisation we did in devkitARM was broken under very specific circumstances (see https://github.com/devkitPro/newlib/issues/16) and the fix slowed it down slightly. For what it's worth testing with our optimisation completely reverted led to a load time of 839.02ms so there's definitely a big impact there. Clearly also working as intended is better than faster but not working as intended.

I tested allowing a bigger buffer for the file I/O in C2D_SpriteSheetLoad which brought the load time down to 76ms so I commited and released that just now. Running pacman -Syu should get you the new library & shorter loading times.

If your toolchain installation is broken then running (sudo) (dkp-)pacman -S 3ds-dev should sort it out.

We don't support old toolchains, old libraries or compilation issues related to them. Ideally if you have a problem then you should report a bug before trying to fix it yourself. We can and often will fix issues fairly quickly when they're reported and we have a reasonable testcase to work with. Thanks for showing us this one and allowing us the opportunity to fix it.

Oh wow, thanks a lot for the quick fix! I imagine thanks to the buffer size increase, my spritesheet loads faster than even before...! In the future, I'll try to be a little better with providing test cases ASAP.

I'd like to note though, the compilation issue was for the latest release (I wanted to try compiling that first before going back). Any ideas on that?

[WinterMute]

Your spritesheet loads should hopefully be quite considerably faster. Let us know how it works out.

I really have no clue about your compile error, sorry. We do compile libctru quite regularly on several OSes and everything is working fine on our end. Have you modified the source at all? Where and how did you get the source?