Identifying Bottlenecks with Performance Monitoring

There are often problems when developing a new project where the code locks up or slows down, and you find yourself asking "Why is my Arduino Code Running Slowly?"

Here we will take you through how to use Visual Micro to find the problem easily using the built-in Serial Debugger.

 

Code Example

We will use a simple multi INO code example with a random bottleneck added in, so we can show how the debugging tools can easily isolate this.

The code example is available to download here.

 

IDE Setup

All we need to do is enable the Serial Debugger in our project, and then set the options shown below to allow the automatic performance statistics to be added.

Performance Monitoring Options in Visual Micro

 

Then we need to add at least one breakpoint to our code, to begin finding the problem, this could be to trap a suspect area of code for example, between two breakpoints.

Suspect code surrounded by two breakpoints

Right click each breakpoint and select Actions, and ensure the "Continue Code Execution" checkbox shown below is checked, also add some meaningful text to the Message box so the output is useful (we added bp1 and bp2 for these breakpoints in this example).

Breakpoint Actions - Ensure Code Execution Box Checked

Build and upload this first step, and we can watch to see where the issue occurs in the Output Window.

Output from our First Breakpoint Pair

Now we can see that it is between these points, not outside them at least.... as we see it sometimes takes 5000ms to get from bp2 to bp1, and the only code there is on line 25...

We can now take this approach to further functions and blocks of code until we find the problem area...

We removed our origonal breakpoints, and we can now add more to the stateChanged() function in the MainCode.ino file, with some additional logging (again we just used "increment_start" on the first, and "increment_end" on the second).

Additional breakpoints for further tracing

If we build and upload it now, we will start to see more about where the delay is being triggered.

Output from our Second Breakpoint Pair

As you can see we now know it must in in increment(), and that is where our random purposeful delay is.

 

Now you can peel back the layers of code, and where the performance bottleneck happens easily with just a few breakpoints.

 

Find Out More

Performance Monitoring Overview

Analog, Digital, Memory, and Performance Reporting