Thanks for the feedback!
I may add an update frequency setting, but I think the benefit would be limited. Selectors without inputs have very low CPU impact (<2 μs/tick each), so players can already get nearly all of the benefit by using a clock to pulse inputs. This has the benefit of not clustering updates on the same tick. That said, we could minimize clustering effects by having two settings (update X selectors every Y ticks), but any players using that would lose the ability to have specific selectors update together. It also has the sticky side effect of having the behavior of selectors be affected by the number of selectors in the game. Adding or removing selectors could break existing circuitry, and a blueprint that works in my save might not work in yours. That said, if there is demand for an update frequency setting, I will look into adding it, but I hesitate to do so.
I'll test out getting the k-th element using a heap if sorting becomes the bottleneck. (I'm interested in finding out how it would compare to using table.sort, since Factorio's version of Lua implements it in C: https://github.com/Rseding91/Factorio-Lua/blob/master/src/ltablib.c#L332) Right now, most of the mod's update time is spent having selectors read their inputs from the circuit network. This is what I'm looking in to now, since we might be able to save time here by noticing when selectors are sharing input wires, and then reading signals once per wire instead of once per selector.
