[Scummvm-devel] Less memory-aggressive plugin management

Marcus Comstedt marcus at mc.pp.se
Thu Nov 8 17:58:41 CET 2007


"Max Horn" <max at quendi.de> writes:

> A more elaborate, but also more complicated approach, would be to split
> all plugins into two parts/plugins: One containing the detection code, and
> one containing the rest of the code. This *should* work (at least for most
> of our engines), assuming the engine implements detection sanely.
> Pro:
> * All the small "detection plugins" could be kept in memory all the time,
> while the full engine plugin only gets loaded when a game is actually
> loaded
> * No problems with mass add either
> * less reload overhead (loading a plugin could actually be painful, too
> e.g. maybe it hurts on DC which uses a CD for storage; I am purely
> guessing here, though)

Loading the plugins does take a little while on the DC, but it's not
terribly bad.  However, there's no potential to use the split approach
you describe here to speed up the DC port.  The reason being that once
the user pops in his original CD-ROM with the actual game, the ScummVM
CD is of course not available anymore.  So in order to have the
correct "full" engine available after game selection is done (which
needs to happen after the CD is removed, and before the engine is
started), all the full plugins would need to be loaded on startup
anyway.

Incidentally, on the DC I do benefit memory-wise from the plugin
system even when loading all the plugins.  This is because code only
amounts for a fraction of the memory usage.  Most of the memory used
is dynamically allocated by the engines to hold loaded data etc.
Hence, even though a fair bit of memory is used by loading all the
plugins, this is less memory than needed to actually run the games
(well, at least when considering SCUMM v6 games; YMMV), and can be
reclaimed before the engine starts allocating.


  // Marcus






More information about the Scummvm-devel mailing list