Slow performance (barbaric allocation of 64 MB)

[kwketh]

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:

libxbr-standalone/test_app.c

Line 101 in 3835e97

xbrData = malloc(sizeof(xbr_data));

due to a massive array size (64 mb):

libxbr-standalone/filters.h

Line 54 in 3835e97

uint32_t rgbtoyuv[1<<24];

[JayFoxRox]

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 XboxDev/nxdk#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 ?