I'd say it depends how much time game spends running those routines. If it hits it a lot, then yeah.. you'll want to manually "run-time" optimize them (00:9532) -- it'd take a long time to dissect each bank ptr correctly through disassembly (data storage).
You'll probably find lots of 24-bit ptrs that I missed, because I never came close to triggering them.
[Bwa ha ha!]
If you keep trace logging, you can run it in this tool:https://www.sendspace.com/file/9z7g4g
Make sure to backup your rom first. Rename it to 'rom'. Rename your geiger tracelog to 'log'. Run exe. It'll parse it and turn things into fastrom banks.
Be careful about it corrupting your own asm hacks if you keep making (changing) them lots of times. Have to be organized. So I'm not officially releasing it or anything. And turned off PEA - PLB detection since there's situations that mess up.
I'll locate some loop offenders and optimize them first. See what I can get before mentioning them here -- have some ideas to test on them.
But I'm going to back off with explanations (since clearly I did a lousy job at it) and let KingMike help you understanding technical problems.
edit: Doesn't look like FastRom will help much. So maybe no point in continuing further this way. I guess there's just too much raster math which is taking the brunt of the slowdown.
Which maybe is why FastRom conversions aren't that popular to fix slow games.
You could always work on your other todo items. Sorry, guess another game that's defeated me again.
Out of curiosity, tried some more. There's a routine that inits the drawing data. Although it uses mvn, dma speeds it up another 2 frames. So 23 -> 20 (fastrom) -> 18 (dma init).
I'll keep poking at it then and upload optimized asm file w/ full ips patch if I can get some more time cut.