[Scummvm-devel] PS2 #9 : performance : node optimization : important

[sunmax at libero.it]

Hi there Max,

> if creation&deletion is causing a slow down, then things won't get
> faster if you replace exists() by "getFlags() & NODE_EXISTS", 
> obviously.

Very true.

If we just replace that method. But my idea was to simplify
the node altogether to improve locality, eg. all the flags
would just be in -1- field (that is surely going to be fit
in 1 EE reg). There would just be -1- method to query those
bits, everything else would be simple bit logic macros.

So everything is already in the faster "mem" which is the
CPU regs, and we are doing just bit logic there. Which is
fast. I would except this to be a bit faster than the
current implementation. Both cause it should be quicker
to create/allocate simpler objects, both cause we drop a
virtual indirection, since getFlags() would be always the
same for every backend [they just have extra macros] ;-)

I know, it's a dirty hack, maybe not worthy to spend time,
but it would be faster. At least a tiny bit ;-)

I actually like the following suggestions:


> there is duplication that can be avoided, etc.:

You know cause I keep reporting them ;-)

Once that I forgot to mention in my gazillions of e-mails
(you see, I should have written an extra one ;-) is that
one of the games that takes longer to start is kyra,
cause it keeps opening and closing kyra.dat. Now, it's
just ~200Kb, so it could keep just a node for that all
thee time during (at least) the startup. Dunno internals
of kyra1, so maybe there is a good reason to do that.


> We should try to reduce the scanning to a minimum

Agreed.


> (that was one of the ideas behind SearchMan, actually:
> It performs a scan once, and caches the result)

Already my best friend ;-)


> * We could revise the FilesystemFactory API to return  
> Common::SharedPtr<AbstractFSNode> instead of AbstractFSNode* in all  
> methods. That would enable the following:

Very hi-tech! It could be worthy a try.


> If the total number of files is small, then you could keep one
> FSNode for each in memory.

Yes, as long as we don't have more than 32 files opened at the
same time we are fine on PS2.

Thanks!
 -max