[Scummvm-devel] Less memory-aggressive plugin management

[Max Horn]

On Do, November 8, 2007 13:53, Kostas Nakos wrote:

[...]
> As expected, the actual binary size for the collected scummvm core and
> engine plugins is larger than building a standalone version. Hence it
> hurts a little more (size-wise) to build using plugins. The problem is
> that when staring up, the launcher goes on and loads each plugin to
> obtain a few things about the respective engine. When a game is finally
> selected all plugins except the target one get unloaded and the engine
> is started.
>
> Hence we've got a critical point here: all the code has to be in memory
> for the launcher. For "normal" use though this can be optimized: The
> launcher can load and discard the plugins (each one, in sequence) and
> retain the info needed from them (can it?). Then when an engine is
> started, the respective plugin can be identified, loaded and run. The
> only time all plugins have to be in memory (I think) is when the user
> presses the dreaded mass add button.

[...]

> I'm not suggesting we hardcode this procedure (again, *if* it is valid
> and doable) but rather have it selectable at least through a command
> line switch/confman entry.

Nah, that would be pointless overconfigurability. The porter should decide
this, so there would be a single #ifdef switch to turn this behaviour
on/off.

>
> What are your thoughts on this?
>

It's not a beautiful solution (no offense intended!) but a very pragmatic
one (no offense intended either *g*). And it's straight forward to
implement, so why not, if it helps you.

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)

Con:
* quite some work, who will do it?
* complicates the build system
* complicates the plugin (loader) code
* slighlty more work for engine authors (although it should be possible to
mostly automatize this, so ideally, they would have little to do)
* the Windows "backlinking is not possible without tricks" issue might get
worse (althoug I hope this could still be solved)


Bye,
Max