loop over all plugins optimisation

[sentinel]

Hi,
I was browsing the code in __Plugin.ino and in function PluginCall, when PLUGIN_WRITE is called, we loop over all plugins. The fist plugin which returns true, has executed the command. This means that:
- a plugin cannot have the same command as another
- we always loop over all plugins to find the command
I was thinking that it would be better if we can instead call only the plugin which has the command we want to execute. So basically, how to know the x control variable of the for loop.
One solution would be that when we write rules, we prefix the command with the plugin id.
Alternatively, we write rules as today and when we press Submit, the software will add the prefix (if there exist 2 plugins with the same command, the user will immediately spot if the wrong plugin is added). This will be done only once when we press submit and not every time the rules are executed.
In both cases, we will decrease the effective characters Rules can have.
Afterwards, an algorithm will use the plugin prefix to determine x (use it as an index to find the plugin).

What do you think?

[TD-er]

I do think there is plenty of such optimizations to be done. A lot of them already have been done in the last few months.
However, I do not think we should ask the user to keep track of such optimizations.
We could keep a cache to store these value and invalidate the cache every time something is saved to the settings.

Let the computer do the administration, not the user.

[arion_p]

Another option that could speed execution of rules would be to compile the rules to some sort of IL(*). That would not only speed up the rules but would also allow more complex rules.

The compiler need not be written in C. It can be written in Javascript and use one of the many open source parser generators available for javascript. The compiler would build the IL code and a symbol table which would be posted to the device with the rules source. Then the core could query plugins for each of the command used. The compiled rules could then be patched to point directly to the correct plugin. Another benefit would be that the user would get immediate feedback on syntax errors. One drawback is that it would require javascript to be enabled on the browser which seems a resonable requirement.

(*) The IL could be quite simple, stack based VM. It could have a very limited instruction set, enough to support math expressions, comparisons branching an calls (to commands)