Executor avoids list comprehensions

[sloretz]

These are some minor optimizations pulled out of #140.

All of them avoid unnecessary list comprehensions. The result is the time spent in the executor during spin_once in the 1kHz timer test using func_number_callbacks drops from 25.5% to 22.2% (average of 100 runs). It's not much, but it might be enough to reduce the test flakiness. I made one change at a time checking the overhead with a script, so I'm confident that each change here is an optimization.

CI

• Linux
• Linux-aarch64
• macOS
• Windows

[wjwwood]

Just had one question about one of the changes, otherwise lgtm.

[wjwwood]

I would be surprised if this is faster, and it appears to be exactly the same behavior. Do you have some reference which supports why this might be considered faster?

[sloretz]

It's a consequence of line 291 where node_guards becomes a generator instead of a list.

An alternative that uses extend instead of append is:

                node_guards = list(filter(self.can_execute, node.guards))
                # retrigger a guard condition that was triggered but not handled
                for gc in node_guards:
                    if gc._executor_triggered:
                        gc.trigger()
                guards.extend(node_guards)

But that increases the executor overhead from 22.2% to 22.6% on my machine. I'm guessing the overhead of calling append for each item in the list is less than the overhead of creating an intermediate list and iterating internal to extend.

[wjwwood]

I see so the removed line was implicitly guards.extend(list(node_guards)). 👍