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

[sunmax at libero.it]

Hi Johannes,

>> 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).

Doesn't configure generate a "plugin table" now which is included in one of 
the cpp already ?

We just need to extend the table generated to incorporate the ID match. It's 
one more step in the same direction. It just does the matching at build time, 
rather than run-time, which is a more efficient approach.

The table and matches would be so simple (as it doesn't require updates unless 
we add new engines or supported game for an engine), that I can't imagine it 
adding more of a few minutes overhead per release. It it's automatically 
generated at configure, not even that ;-)

>> Do you have any measurements on the boot times between cached and 
>> uncached builds?

Yes. Boot 15s (uncached) vs 1m40s (cached) on my PS2.

Even static (all plugins statically linked, which has been the default so far 
for PS2 release) is much faster than cached, just 40s.

> 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. 

I know, and waiting 2 minutes before you can start a new game is also very 
frustrating.

The first time I saw this, I actually thought PS2 hang up (and so will most 
users and just power cycle their PS2). It doesn't look good.

>This makes me wonder: Is it really the plugin loading which is this slow 
>or is the detection itself just slow?

Detection is quite fast: when using static plugins it's under 10s on PS2 vs ~2 
minutes.

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
>