[Scummvm-devel] R: Re: Dynamic Plugins (uncached) - optimization

[sunmax at libero.it]

btw: don't we already have a similar approach with "plugin_files" in scummvm.
ini ?

Although that's currently just a match between gameid and plugin.

We would be extending the concept to "folder" where it matches a 
gameid/plugin.

We just try to make scummvm users life easier and better use of their time, by 
doing the matching for them at build time.

It does make a big difference on embedded platforms.

Thanks,
-max


>----Messaggio originale----
>Da: lordhoto at gmail.com
>Data: 25/01/2014 21.26
>A: "sunmax at libero.it"<sunmax at libero.it>, <scummvm-devel at lists.sourceforge.
net>
>Ogg: Re: [Scummvm-devel] Dynamic Plugins (uncached) - optimization
>
>On 01/25/2014 08:18 PM, sunmax at libero.it wrote:
>> no need to load them all.
>>
>> As we know a-priori that "comi", "dig", "mokey2", etc. all maps to "scumm.
plg"
>>
>> So if the folder start with "comi*", "dig*", "monkey2*" etc. we try to load
>> scumm.plg first.
>
>> So we just need a table to match them, and to enjoy the very best 
performance
>> out of dynamic plugins.
>
>
>That's information which is not stored somewhere outside the individual 
>plugin files though. We only build such a map after games are detected 
>(i.e. only for gameids where we actually had entries). This is done 
>inside the "plugin_files" domain inside the config file with the 
>uncached plugin manager.
>
>Right now it's only possible to generate one on the fly by loading all 
>plugins one after another (on startup). Hardcoding such a list would 
>again increase the maintance overhead (by introducing redundancy).
>
>> Cached is very slow to start on some embedded devices. And then if you 
decide
>> to add more games after you play one, still have to go through the same 
drill
>> and 3-5 minutes of patience for each addition.
>
>Do you have any measurements on the boot times between cached and 
>uncached builds?
>
>For cached it will reload all plugins after you return from a game, so 
>it shouldn't fall back to the uncached detection logic in this case. 
>This makes me wonder: Is it really the plugin loading which is this slow 
>or is the detection itself just slow?
>
>// Johannes
>