If you can combine the swizzling into a scanline renderer you might be able to get it close to free, depending on how the rest of the renderer works.
The best thing that can be done to optimize SNES9x (and this goes for any of the ports, even the PocketSNES tree) is for a new renderer to be done, preferably with the inner chunks having ARM ASM versions. I've looked through the stock SNES9x renderer (as of 1.52, the version used here) and it can't be very fast. I don't recall exactly what changes PocketSNES made, but I seem to remember it having the same sorts of problems. The SquidgeSNES renderer avoided some of them and had some of its own optimizations, but at some expense of accuracy. I don't think this renderer is available for PocketSNES, but I could be wrong.
Here are some of the issues:
- Tile rendering goes through function pointers per-tile which involves a lot of parameter passing and loading global arrays. This eliminates opportunity to perform optimizations such as strength reduction on loops and hurts register allocation, especially hard on RISC platforms. It's not too bad in the typical cases where you can render an entire tile at a time, but where the tile is forced to be broken up line by line, like when scroll or palette is changed every line, you'll feel a lot of pain from this. It's better for the switching to be done per-line instead of per-tile, even at the expense of having to generate more code.
- Z-comparisons are done on every pixel for priority sorting. This is especially expensive here because screen-wide z-buffers are used, which will cause a data cache miss on every new cache line from the z-buffer (for 32-byte lines that's every 16 pixels).. on platforms like Caanoo a cache miss can be over 70 cycles. It'd be better to split the BG layers into separate priorities, draw them in sorted order, draw OBJ, and combine OBJ. But there are other methodologies which I think are better than that too, they're just too long to describe here.
- Color math is done on every layer pixel write. This both wastes cycles on overdraw and causes another obligatory cache miss into the screen-wide sub-screen buffer. It'd be better to do it in a post-processing pass per-scanline.
- Main screen and sub screen are drawn in completely separate passes, which means twice the work is done when color math or hires is turned on. It'd be better if the line renderers drew two pixels where necessary. Especially if Z-combining isn't necessary per-layer.
- Mode 7 rendering would usually be (probably significantly) faster if they cached current tile pointers and only reloaded when offsets moved outside of the tile.
bsnes avoids some of these problems in its line-based renderer, but has some of its own unique problems, so I wouldn't necessarily recommend trying it.
I've got some rendering methodologies in mind that I hope to describe soon. They might be useful for making fast renderers for a lot of platforms, including SNES. But writing new rendering code would be a ton of work and I doubt anyone will do it.