I'm happy to announce that I now have the first working prototype for a dedicated LMMS Memory Manager written and functional.
A few caveats: 1. It doesn't work with QObjects. I'll elaborate on that a bit below... 2. Haven't really done any testing for leaks or such, there may be bugs to be found... 3. Not sure of the performance benefits yet either, but I think the results will be positive Now, for a bit of tech talk... The way it works is, it allocates a quite big single chunk of memory at startup (size can be adjusted, could be made configurable). This memory is then divided to chunks of 64 bytes, and these chunks are used to dispense memory for objects needing it. If the chunks run out, a new pool is allocated - this can mostly be avoided by setting the initial size large enough. The header file also provides a macro, similar to Q_OBJECT, which can be added to class definitions, and what it does is it overrides the class's new/delete operators so that the class uses the memory manager instead of heap allocations. The reason this doesn't work for QObjects is that apparently QObjects already override new/delete, and thus those can't be overridden again. Oh well, but shouldn't be an issue as QObjects are usually mostly GUI-related stuff and don't need to be created/destroyed on the fly. Maybe someone can figure out a workaround for this later. This also means that we can't override new/delete globally, which would have been an easy way to do memory management in the entire software - so this means a bit of extra work: all classes that want to use the memory manager must now add the MM_OPERATORS macro to their header file. I'll be submitting the branch up for testing soonish. That is all. ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ LMMS-devel mailing list LMMS-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lmms-devel
