[Milhouse]

Be aware that mallocs above the threshold are much more expensive (in arm CPU time), so a high threshold is beneficial for performance.
When John's back I'll check what ram gets dynamically allocated and whether any large allocations can be "pooled".

Feel free to add MALLOC_MMAP_THRESHOLD_ to subsequent builds for further testing, but personally I'd favour a slightly larger value (32K/64K) for performance.
But I guess having the smaller value for testing purposes may be interesting (if no one notices the difference then maybe it's not important).

Yes, I thought there might be more CPU overhead when using smaller chunks. Elysium is playing OK with 8K but if there are problems then we can try larger chunks.

Hi Popcornmix & Milhouse,
For the interested, (I design real time software for flight simulators) but uninitiated, if you have a spare moment, could you explain what you think is happening, I was always under the impression that when you malloc some memory, as soon as you do a free of that same memory, it's all returned? or is this a feature/bug in the latest compiler. I know what fragmentation is, but it would imply that there are lots of chunks of memory malloc'd which are hanging around, blocking subsequent mallocs, getting worse, each time the video (in this case) is played? or I don't understand. :-(
Regards, Kevin.

There is additional information if you follow the links in the original PR1286, in particular the bugzilla link.

I tested with 8192 and 65536 and I don't see much difference compared to default. Kodi fills up the whole available RAM after ~ 8-12 runs. 8192 seem to be even worse that 65536.

Are you sure you applied MALLOC_MMAP_THRESHOLD_ correctly? Can you re-test with #0127 (with 8192 threshold)?

I've briefly tested #0127 with 8192 and the deficit after...

1st playback: 15MB
2nd playback: 24MB
3rd playback: 29MB

which is broadly in line with my previous 8192 results (and significantly better than without any MALLOC_MMAP_THRESHOLD_).

Not enough time for 8 plays, need Zzz.