Thanks for the hint, Zajo. I will have a look at it. It looks like a bit of work, especially in a C environment.
Zajo schrieb am Donnerstag, 25. Februar 2021 um 01:57:50 UTC+1: > On Wed, Feb 24, 2021 at 9:46 AM Dieter Weidenbrück <[email protected]> > wrote: > > I'm working on a graphics authoring app. Naturally, there are lots of > primitives stored in variable size mem blocks. The quantity can easily > exceed a couple of hundred thousand blocks. > > Loading such content into fresh memory is not the problem, however, > after editing/changing the content the heap will be cluttered with small > blocks. > > > > It is not really feasible to load a new instance and reorganize all > blocks there, although that might be a last effort solution. > > > > Is there any recommendation on how to overcome this problem? I thought > about reserving a large chunk of memory (approx 1.7 GB to leave room for > other allocations) using malloc at startup time and then manage all small > blocks myself. Looks a bit like brute force though. (I'm not caring about > mobile phone usage) > > My method for fighting fragmentation and performance issues with memory is > to use shared_ptr-based factories for everything. It has a type-erased > deleter so that you can organize your data in different pools and caches > not only based on type but even per-instance. Of course this may not be > practical in case you're dealing with a mature code base that does not use > shared_ptr. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/86ea8758-719c-4453-b8ec-d2799fc08a5en%40googlegroups.com.
