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

[Max Horn]

Am 03.03.2009 um 07:54 schrieb Johannes Schickel:

> Max Horn schrieb:
>> 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).
>
> Kyra opens a .PAK/.VRM/.APK/.TLK file every time:
>
> - The code wants to retrieve file size of a file embedded (that  
> could really be cached aye)
> - The code reads data from an embedded file
> - The code retrieves a file stream to an embedded file
>
> Since there are many file entries in kyra.dat for Kyra1 for example,  
> it is clear why it opens "kyra.dat" that often. On startup some  
> files from STARTUP.PAK are loaded it seems. I have currently no idea  
> why FNORTH.PAK is opened though... :-). Well I would need to look  
> into that, so far I thought the backend is responsible for caching  
> file opening,

So far we really have no policy on that, I think... We should maybe  
discuss how we should handle this. Of course if the backend handles  
"caching" of file handles, that would benefit all engines at once.  
OTOH, for the engine author it should be much easier to keep track of  
which files will still be needed.

Max, Backend side caching could be done via some kind of "use  
counting". When a file is closed by the client code (i.e. the  
backend's stream object holding it is deleted), don't close the file  
immediately; instead, put the handle into a small cache, e.g., a  
Common::Hashmap which maps paths to handles. Also store the time the  
handle was closed with it. If you run out of handles, resp. more than  
a certain threshold of file handles are open, close the one for real  
that was used least recently, i.e. has the earliest "close" time.  
OTOH, when opening a file, first check your cache of file handles to  
see if it is already there. You must not forget to seek(0) and reset  
error flags.

Of course, yet another idea would be to implement this in a generic  
layer, so that all ports can share this feature.



> else wise I would need to add some code to cache file streams on the  
> fly...
>
> // Johannes
>


Cheers,
Max