FR: Method for measuring CPU load

[lure23]

I'm starting to use Embassy and one curiousity is about how much CPU headroom there is, when I'm running a certain application. In other words, how long does the Executor sleep?

This issue is intended as a place for discussion / collection of knowledge. I start by listing the few resources I've found.

Since I am new to Rust and Embassy, I am not yet prepared for providing a PR. However, I will be experimenting with this need.

Links:

• "Measuring Cpu usage with rust Embassy" (blog, Jun 2024; on "ARM 32-bit")
• "Add a (optional) way to measure CPU load on Cortex M executor" (PR; open since Apr 2024; on Cortex-M) [2]

Opinions:

• I would like to see this as a feature, so that it can be enabled in debugging but left off in production. [2] uses the feature name measure-cpu-load.
• I don't think multi-core is an issue, since (as in ´[2]`) such instrumentation would be executor-specific. I presume multi-cores (at least ESP32 normal+low power) have separate executors for the separate cores.
• The API should, preferably, be unified across architectures.

[Luctins]

I have a similar issue: I'm uncertain if my current performance bottlenecks are in IO or in in the microcontroller core itself.

Also using the executor itself would be a good bet since the information would be most available there. Maybe tracking some form of Id for each async task could be a start?

[Gibbz]

It would be good to have a profiling tool. I have a basic one I've written for using to time how long code takes to execute.
Possibly having something like this all as one crate would be useful.

[lure23]

I wrote the FR 2 weeks ago. In the mean time, I have realized the feature (as a centralized monitoring feature) may not be as necessary as I originally imagined. My thinking was desktop based, I presume.

The code I work on (as many embedded code, I imagine) works as repeated "frames", or as a state machine. By timing how much time each operation within a "frame" takes, I have gotten a good understanding of where the time is spent - and as a side benefit how much CPU budget remains, until the core wouldn't be able to carry everything out each "frame".

I will keep the FR open, as it was intended to catch discussion on this issue.