While looking at something else I noticed in procmon that MAME has an interesting habit of reopening files that do not exist. Now on a local file system this is probably not too bad. But on a network filesystem it is sort of bad.
Current results are kind of promising.
I added in a std::map to cache the negative 'no file found' results returned from open_funcs[ i](m_fullpath, zip) in the fileio.cpp file in the attempt_zipped method. Just bashed it in as a global for a quick test. Would be nicer to make it part of the class.
I fed in '-verifyroms pacman' for the parameters
It went from 2574 file events most of which were negative to 1251 file events. A good portion of the remaining were dll loads and mame.ini reads (which oddly it seems to do twice).
From my testing with '-verifyroms pacman*' (with wildcard) I am getting about 9 to 15 seconds faster reads fairly consistently. That is with wall clock time tests. Would need to add a bit of logging to get it more exact. At least for my network.
Now obviously the best case would just to be to run the whole thing from a local machine. Do not have the room at the moment. I suspect it would still help but not as dramatically.
Just for an interesting test I did a drag race between the two methods for verifyroms. The old way got to 12 roms before I killed it. The new one got through 76 roms before I killed. Killed them within 1-2 seconds of each other. Not bad and noticeably faster. Individual game load does not seem to have much difference at all.
Downside to this method is it probably just looks straight up like a memory leak with an ever growing map. Though I have not noticed much in memory manager. Another downside would be if someone starts the prog up and then afterwords drops files in. It would think the files do not exist until restart. Also it probably would be better to run down why it is trying to open paths that do not exist in the first place. But I was a bit bored and have been meaning to try this for a few weeks.