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

Max Horn max at quendi.de
Tue Mar 3 02:40:16 CET 2009


Am 02.03.2009 um 20:19 schrieb 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 *strongly* doubt that it will have a noticeable impact. Based on all  
my past experience optimizing code for lots of small devices, I really  
don't believe that *this* is where we burn CPU cycles. Working on  
this, you likely would wast a lot of time for a 0.1% speed improvement  
that makes the code a lot harder to read and maintain. It's not as if  
we call exists() 1,000,000 times in a row!

If performance is bad, it's more likely to be caused by other things:
* Excessive malloc/free calls (allocating 10000 nodes and releasing  
them again can be slow depending on your memory manager);
* reading disk data in general (if memory I/O is slow, then disk I/O  
is glacial)
* reading disk data *unnecessarily* (e.g. reading the directory data  
for the same directory 5 times instead of once)
* other areas you might not even have considered yet :)
...

[...]

> Once that I forgot to mention in my gazillions of e-mails
> (you see, I should have written an extra one ;-)

No, you should have focused on writing one on all FSNode/file related  
stuff that mentions *all* problems *ggg*.

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

It is true that kyra opens kyra.dat 86 times in a row during startup.  
That doesn't seem good. Johannes? It also opens STARTUP.PAK 10 times  
in a row, and many other files are opened like 5 times (e.g.  
FNORTH.PAK etc., right at the start of the game).

[...]

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

Uh, wait a moment -- an FSNode by itself and an opened file are two  
different things. Are we talking here about *FSNode* (which a are  
classes that keep track of objects in your file system), or file  
handles (which keep track of currently opened files) ? You may wish to  
cache the latter, too, but that's a very different design goal.


Bye,
Max




More information about the Scummvm-devel mailing list