[Scummvm-devel] PS2 #9 : performance : node optimization : important
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",
> 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
* 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.
More information about the Scummvm-devel