search

Treeki / libxbr-standalone

Library implementing the xBR pixel art scaling algorithm
107 stars 21 forks source link

Slow performance (barbaric allocation of 64 MB) #3

Open kwketh opened 6 years ago

kwketh commented 6 years ago

Not expecting this to be fixed, but this is just for future reference and/or if anyone is curious why a lot of memory is allocated for any filter, no matter what image size.

(lldb) print sizeof(xbr_data)
(unsigned long) $0 = 67108864

xbr_data is allocated at:

https://github.com/Treeki/libxbr-standalone/blob/3835e97d2f991b867a9764fa6ace730d25e4a19e/test_app.c#L101

due to a massive array size (64 mb):

https://github.com/Treeki/libxbr-standalone/blob/3835e97d2f991b867a9764fa6ace730d25e4a19e/filters.h#L54

JayFoxRox commented 4 years ago

There were 2 independent ports of a game (which uses libxbr) to original Xbox - and neither of them worked.

After investigating this as a potential toolchain issue in https://github.com/XboxDev/nxdk/issues/324, we realized this is an issue in libxbr. On original Xbox, we only have 64MiB of RAM - so this code could never work.

Aside from being "stupid", the code probably causes performance issues, too: For more than a decade, CPUs have been faster than memory, so random-index lookups in the LUT will probably trash the cache. If the CPU just did the math instead (or used smaller LUTs), it would likely be faster.

The same problem exists in ffmpeg but probably doesn't trigger on most modern machines, or people don't care for the performance.

I think this code is truly horrible and should be improved. Is this project still being maintained @Treeki ?