Comparison of overheads of micropython operations

[stijn]

running against a stock firmware image

I'm fairly sure there are also a number of core types present in stock firmware which have their own attr implementation, possibly making them behave differently with regards to property performance in comparision with Python classes.

[pythoncoder]

I don't think you should be choosing the programming constructs in your program based on microsecond differences in execution time...

I agree with all of that. In spades

In terms of practical experience developing MicroPython applications (and elsewhere) the key is to identify the section of code which presents the bottleneck. Often it's quite small, maybe a single function or method. You can then pull out all the stops to optimise that: cache bound variables in locals, try different constructs, use Viper, measure the outcome of every change. As you say, if it's still too slow use the inline assembler.

If the code is to be maintained by others comment the hairy section thoroughly.

The bulk of the code should be written for clarity and ease of maintenance.