[Scummvm-devel] Less memory-aggressive plugin management

Kostas Nakos knakos at phys.uoa.gr
Thu Nov 8 13:53:28 CET 2007


Hello,

Having recently migrated the wince port to supporting plugins has lead
me to the following observation:

(Forewarning : Please do not flame me about any misconceptions and/or
lack of related code studying, as I'm short of time recently. What I'm
talking about may be /utterly/ wrong. Please point out to me where I'm
wrong here. Thanks in advance :-) )

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.

Of course, this way things take longer to get done (all that
loading/unloading/reloading) but we keep memory usage to a minimum.
Needless to say I would like to have as lower memory footprint as
possible. Also, in the mass add situation when a plugin fails to load
due to low memory, the user can be warned that mass add won't work
exactly right (or even bail from it).

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.

What are your thoughts on this?

Best Regards,
Kostas




More information about the Scummvm-devel mailing list