did you know you could fe:
-- aka "performOnceASAPThenEverySecondThereafter" timer.performWithDelay(1, function(event) event.source.\_delay = 1000 end, -1)@davebollinger I’m vaguely aware of those internals, but a bit paranoid about tampering with anything not nailed down. :D (I do seem to remember @Lerg going to town with them on an episode of Corona Geek, though I couldn’t say which one.) But of course the topic is all about sussing these sorts of things out. 
@remiduchalard, thank you for sharing your approach
Your approach is interesting, you only use 1 runtime, for multiple timers. for a scene that uses a lot of them, it looks very useful. Thanks again for sharing.
If I may give you an advice, try not use to many table.insert or table.remove. they are way overkill functions and resources consuming.
if you only need to insert a value in the last place of a table use table[#table+1]=newvalue.
for deleting only if its the last value, ofc: table[#table]=nil
but I think you already know that, for the example and showing how the timer works it’s more than enough 
@carloscota what I have wrote is very dirty ( I know it)
When I write some code and I know it will be call many time I try to haven’t linear time of execution per call. What I try to say :
for one use if it’s take 1ms for 10 use I try to have less than 10ms.
When I don’t keep in mind to try to have a log or square graph of execution time I very often finish with something like this Time=Number of use ^(x) (with x>1)
Also when I build my function I try to have a lot of easy access to data (read only or read and write). When I write a code for only myself I try to have as much as possible global value. It’s a bad practice for big project but when you work alone on a bunch of code, it’s help to win a lot of coding time, line of code and performance. You don’t have to make getter and setter.