Ex C64-games coder here! — If your sprite multiplexer was taking most of CPU during the screen draw time, then honestly it was not a particularly great multiplexer! ;)
Most decent multiplexers took just a scanline or two/three, multiple times down the screen (i.e. whenever relocating any already drawn sprites) — often with decent sized gaps (time when the CPU wasn't involved in manipulating sprites and could do other things), with a larger chunk during the offscreen period / at the bottom of the screen, when one was preping the data (mostly sorting the sprite's y-coords) for the next frame's screen draw.
— During debugging/etc, we'd often enable colour changes to the screen border, at the beginning and end of the multiplexer code (for both the interrupt stuff in the playfield, and the non-playfield section), so we could visually see how it was working/performing.
The border changing thing has just reminded me how bad the development process was using the commodore assembler with a 1541 drive which was horribly slow. assemble, dump image, reboot, crash, reboot, load assembler, try and work out what had happened :)
At some point I ended up with a PC running a system called, I think PDS, which was a cross assembler with dongle to push the image straight into the memory of the C64. I even think you could inspect and change memory on the running machine - it was amazing!
Yeah, we all used PDS too, although not originally. Pretty good system, particularly for that era, and cost/capability-wise (though they weren't that cheap, and folk eventually started cloning the boards for them, IIRC).
I remember it was annoying to have only 8 main source files in PDS though, most big projects went past the 8 files of however many kb (although it could also handle include files, which was how one got around that limit).
Although when I actually started out as a C64 games dev, my dev system was a BBC Micro B, linked to a C64. Not quite a cool as PDS, but it could assemble code 2x the speed of the C64 (the processor clocked twice the speed on the Beeb), and it was great having a separate 'host' system for development.
Sure, the "nice" way of doing it is to rely on the raster interrupt. But I've also seen way too much C64 code where pretty much everything ran in the interrupt handler, with associated stupid busy waiting because it saved people from having to synchronise. I'd guess more commonly for cheap and cheerful ports from less capable machines, but it's been a couple of decades since I've actually looked at any of this code.
Most decent multiplexers took just a scanline or two/three, multiple times down the screen (i.e. whenever relocating any already drawn sprites) — often with decent sized gaps (time when the CPU wasn't involved in manipulating sprites and could do other things), with a larger chunk during the offscreen period / at the bottom of the screen, when one was preping the data (mostly sorting the sprite's y-coords) for the next frame's screen draw.
— During debugging/etc, we'd often enable colour changes to the screen border, at the beginning and end of the multiplexer code (for both the interrupt stuff in the playfield, and the non-playfield section), so we could visually see how it was working/performing.