improving efficiency of uTasker kernel

[schveiguy]

I have spent some time now getting to know uTasker, and I think I may have seen some room for improvement on the scheduler/driver.

First, all operations on tasks use a linear search through the task table to find the appropriate task.  By sorting the tasks, you can use a binary search that should reduce the runtime of searches.

But even without this, it could be possible to cache the index of tasks you care about.  These can be global variables that are set on startup and used instead of the character constants.  This eliminates the need to search whatsoever.

In addition, the timer resources involve a linear search as well, and this could easily be cached on startup (in fact the index is present in nr_of_timers in the start function).

I don't know what the performance/power consumption is without these changes, but I expect from all the calls to things like sending events and waking up tasks that this can save a significant amount of cycles.  What do you think?

-Steve

[mark]

Hi Steve

For highest speed efficiency I could imaging a look-up table for the task entries and the timer entries. Then there would be no need to search for anything. The look-up table can be constructed when the task and timer lists are created.

However for maximum efficiency these tables would need 256 entries (so that a task name can be directly converted to a pointer) - that makes 1k. Therefore the compromise is against RAM use.

There are probably compromises in between.

I would suggest that if optimisation for speed is performed it should go the full way, otherwise the search method (optimised for memory, as now) is the other alternative extreme. I wonder however whether these actions are critical in most projects - the ordering of tasks also allows some control of search speeds since the first ones entered are always the faster to find.

Regards

Mark