Welcome to Emulationworld

Forum Index | FAQ | New User | Login | Search

*View All Threads*Show in Threaded Mode


Subjectclrmame based on database new Reply to this message
Posted bySyNTaXer
Posted on10/15/06 03:19 AM



hi, was thinking a lot, how to increase the performance in clrmame. and my idea was to use a database to catalog all files also inside archives (like the indexing used by windows ntfs) with it's crc and position where to find. that means, once you've scanned your files, it's faster to find files with specific crc for fixing or rebuilding.

what do you think about?




SubjectRe: clrmame based on database new Reply to this message
Posted byRoman
Posted on10/16/06 01:56 AM



Once the diskcache got the files cached, a full mame scan takes less than 7 seconds. And even for indexing you have to read them once (and the scanner accesses the files only once anyway). As long as the name of the set is already correct, it's a direct file access. So there is no need for an index and you got no real benefit from it.
Since you need to reread the files anyway (because something could have been changed), the scanner has to reaccess the sets anyway. The rebuilder is filebased and so an indexing mechanism isn't needed since it works the other way around. It reads a file, matches the hashvalue and recreates the file in the destination.


Roman Scherzer



SubjectRe: clrmame based on database Reply to this message
Posted bySyNTaXer
Posted on10/16/06 09:50 AM



> Once the diskcache got the files cached, a full mame scan takes less than 7
> seconds. And even for indexing you have to read them once (and the scanner
> accesses the files only once anyway). As long as the name of the set is already
> correct, it's a direct file access. So there is no need for an index and you got
> no real benefit from it.
> Since you need to reread the files anyway (because something could have been
> changed), the scanner has to reaccess the sets anyway. The rebuilder is
> filebased and so an indexing mechanism isn't needed since it works the other way
> around. It reads a file, matches the hashvalue and recreates the file in the
> destination.
>
>
> Roman Scherzer
>

you've cleared up some things, thank you.




View All Threads*Show in Threaded Mode