I also think the principle of running on ranges of instances at different ticks is not a good way to solve the problem. It potentially raises more tricky problems:
- it's a subtle way to introduce framerate-dependent logic. It's essentially like saying "every N ticks", which is framerate dependent. On a high refresh rate screen the "every N ticks", or "for-each across N ticks" will run faster, and this can produce a different and potentially unwanted result, with parts of your logic running faster than they ought to. Using dt to avoid this is also extra-tricky, because you really want a time step across multiple frames. So you can end up introducing hard-to-find and hard-to-fix bugs in your project that won't show up until later.
- it's very difficult to schedule efficiently. On a high-end machine you might want to go through 1000 instances per tick. However on a low-end machine that might still kill performance. If you reduce the number though, the high-end machine has wasted capacity - it could easily be processing many more instances but you had to put in an arbitrary limit for low-end machines. So now high-end machines have to pretend to be a low-end machine, cancelling out their performance benefit. Determining the right number depending on the hardware is a notoriously tricky problem. This is compounded when you consider: should it go through N instances per tick? e.g. if you process 100 instances per tick regardless of the total count, then you end up with increasingly long latency to process all instances (at 60 FPS, it takes 33ms with 200 instances, or 1000ms with 6000 instances). Or do you go through all instances per N ticks? Now you have an unbounded processing limit again, so it can still end up slow, defeating the purpose of doing this.
I think there are several different existing approaches you could use that avoid these problems completely. For example you could use a boolean instance variable to opt-in instances to processing with a certain event. Or you could only process objects on-screen or nearby. Or you could find a different way to approach the problem that doesn't involve heavyweight for-each loops. It depends on exactly what you're doing.