- --
Viewing Issue Advanced Details
[ Jump to Notes ]
ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
---|---|---|---|---|---|
04355 | Interface | Minor | Always | May 23, 2011, 05:05 | Jul 27, 2017, 13:36 |
Tester | Tafoid | View Status | Public | Platform | MAME (Self-compiled) |
Assigned To | Resolution | Fixed | OS | ||
Status [?] | Resolved | Driver | |||
Version | 0.142u3 | Fixed in Version | 0.188 | Build | Normal |
Fixed in Git Commit | Github Pull Request # | ||||
Summary | 04355: -romident performance has greatly decreased | ||||
Description |
Recent work on the core has cause -romident not only no longer displays the data as it used to, it also in 0.142u3 has now become unbearably slow in processing the request. Another minor annoyance is that starting in 0.142u1, columns are misplaced and not lining up as before. Prior: mp1_2.1c = mp1_2.1c mappy Mappy (US) = mp1_2.1c mappyj Mappy (Japan) Now: mp1_2.1c = mp1_2.1c mappy Mappy (US) = mp1_2.1c mappyj Mappy (Japan) |
||||
Steps To Reproduce | MAME -romident any set with version 0.142 or earlier then compare to the speed and output of 0.142u3. | ||||
Additional Information | Also reported by AWJ and Haze | ||||
Github Commit | |||||
Flags | |||||
Regression Version | 0.142u3 | ||||
Affected Sets / Systems | |||||
Attached Files
|
|||||
Relationships
There are no relationship linked to this issue. |
Notes
8
No.07469
Tafoid Administrator
May 27, 2011, 00:44
|
Breakage is between r12291-r12301 - Suspect r12301 as culprit. |
---|---|
No.07860
Tafoid Administrator
Nov 2, 2011, 20:56
|
The formatting was fixed, but the issue with performance remains |
No.10866
Firewave Senior Tester
Jul 26, 2014, 14:06
|
The performance issue is related to the software lists being parsed again for each file. |
No.10869
Robbbert Senior Tester
Jul 26, 2014, 22:34
|
The software lists must have something to do with it.. HBMAME and MESS have roughly the same number of sets, but -romident with HBMAME produces instant results, and we all know how long MESS takes. I don't know how many software sets we have (is there a way to find out?), but it must be in the tens of thousands, if not more. The only thing I could suggest is to split -romident so it only does roms, and a new command (-softident?) checks software lists. Unless, of course, someone makes the process more efficient. |
No.11383
etabeta Developer
Jan 18, 2015, 11:18
|
I think this won't be ever fixed. Parsing software items as part of the -romident process is a useful feature. If an user want to exclude this, it is enough to point -hashpath to an empty folder and the original performance would be recovered. |
No.11384
Haze Senior Tester
Jan 18, 2015, 13:34
edited on: Jan 18, 2015, 13:36 |
yeah, this was never about the software lists, the original bug was created when the internal -romident performance of just MAME took a nosedive. when you've got software lists, with thousands of roms in them, and have to parse the XML (which is not a quick process either) it's expected to be rather slow. some caching logic *might* make it faster (things like CLRMAME can process the entire database of hashes, identify a file and decide where any given file goes significantly faster due to the way it caches the data) so I'd definitely argue it could be improved, but it isn't what the original bug was about. |
No.11385
Firewave Senior Tester
Jan 18, 2015, 14:29
|
The problem is, that the XML software lists are being parsed over and over again since the processing of the input data is sequential. Making the processing either smarter or add some caching will greatly improve the performance. It requires some major reworking how -romident works at the moment, so it will not happen soon, but it will happen. |
No.14020
Osso Moderator
Jul 27, 2017, 13:36
|
As of 0.188, speed is comparable to MAME 0.142. |