Resolve deprecation status of static timers

[marcelstoer]

Ever since @djphoenix added an OO API to the timer module with f1afe7b over two years ago our documentation has been saying that

Static timers are deprecated and will be removed later.

That's a bit problematic for two reasons:

1. The note is just in the documentation and not reflected in the code. One should use platform_print_deprecation_note in tmr.c to print a deprecation note to the console (like we do elsewhere) whenever a static timer function is used.
2. I couldn't find a follow-up issue here that would ask for the actual removal of the static timers. Who would/could/should have done that? Things get forgotten so easily.

It's all history now but I'd like to resolve that deprecation note in the docs. IMO we should either removed it or follow-up with code changes.

Tagging @djphoenix, @dnc40085 who is listed as the module maintainer in the docs and @devsaurus who ported the module to the ESP32 and thereby removed the static timers if I'm not mistaken

[jmd13391]

IMO, Removing the static timers is a bad idea. Legacy compatibility aside, using static timers consumes less memory than using the OOP timers.

My vote is to remove the deprecation statement from the docs.

[marcelstoer]

Legacy compatibility aside

That's why we have been using platform_print_deprecation_note. We keep that in the code for a couple of releases (i.e. maybe half a year) until functionality is removed. That gives developers ample time to adjust their code where necessary.

using static timers consumes less memory than using the OOP timers.

How much?

[jmd13391]

"How much?"

That's a question best answered by @TerryE ;-)

[marcelstoer]

That's a question best answered by @TerryE

I disagree...Terry didn't make any such claim (yet) 😉

[TerryE]

Marcel, all I take by Joe's comment is that of the committers, I possably have the best understanding of the Lua VM internals and VM and so can answer the Q: what are the memory +/- of using the Object form of timers vs the static form? That is providing a data point which aids any decision that we make. 😊

[jmd13391]

"Terry didn't make any such claim"

Actually, he did... I can't recall at the moment the specific context of his statement but I do recall it was to justify his use of static timers in a snip of Lua code he wrote (if pressed, I will set off on a quest to find and re-post the statement). Also, I suggested Terry supply the answer as IMO, he is a very knowledgeable resource on the subject.

[nwf]

AFAICT from reading the code:

• each timer costs an os_timer_t (4 pointers, 2 32-bit words, and a bool padded to 32-bits by C structure rules), an additional 3 32-bit words, and one 8-bit word which will be padded to 32-bits because of C structure padding rules. That is, each timer has a heap cost of 11 32-bit words in size; the static ones, of course, pay this cost in the static .data section, not the heap proper. If active, each timer will additionally consume one (if static) or two (if dynamic) Lua registry indices.

• everyone always pays the 77 32-bit words cost in .data of the 7 (NUM_TMR) static timers, if the tmr module is compiled in, regardless of their use.

I think, given the very low additional footprint of dynamic timers and their superior programming model (much more OO, much less assembler / "which number am I not using at this point in the program?"), that static timers should be completely retired, the tmr.c code simplified, and the 308 bytes of .data made available to the dynamic heap.

[marcelstoer]

I think, given the very low additional footprint of dynamic timers and their superior programming model ... static timers should be completely retired

👍 Any volunteers?