yep, avoiding string / hash lookups will give you nice speedups.
the smc777 one is dramatic because like I mentioned in the commit I did, it was doing the hash lookup in the inner most (per pixel!) draw loop, plus on some very heavily used read/write handlers.
of course that's not a magic go-fast solution, but quite a lot of drivers did experience slowdown when everything was converted from index based (for io, regions etc.) to tagged so you can win back some speed that way.
I'm trying to establish why x68k is slow tho, admittedly it's pretty useless with broken floppy, but once everything works again it has the potential to be one of the flagship drivers. Profiler etc. all point at timer callbacks, and while there is some rather horrendeous hash looking up in some relatively high frequency timers (keyboard, mouse callback) those aren't the source of it because I can disable them completely and yield very little. I have 58% time in 'timer callbacks' and 30% 'unaccounted / overhead' as the main drains according to the profiler, and not even gprof and/or -profile with a symbol / debug build are pointing me in any better direction.
As I said, a little pointless while the driver is broken anyway, but it is the type of system we need to nail if MESS is to gain any kind of popularity because it's often talked about and has a decent number of original creations (shmups etc.) in addition to the arcade ports. Drivers like that are important for MESS IMHO and none of the standalones are in 'other league' quality (yet)
