Arduino Debugger Extensibility Performance Considerations

by Visual Micro 7. August 2012 14:00

Aug 2012: First draft - The Visual Micro Extension Framework

Visualizations provide a simple way to build powerful fully featured graphical plugins. It is possible to code both efficient and inefficient visualizations, the latter should be void!

Unfortuately all this power and flexiblity means that it is possible to create unwieldy and slow plugins that consume fast amounts of cpu power. This document provides a place to develop useful tips and suggestions that will help ensure the debugger continues to run at an efficient speed.

The Visual Micro interface provides a number of standard events that should be used to perform a little work as possible. For example in the OnDebugInit event is called once each time a debug session starts. The event should be used to initialise as much as possibly ensuring that a timer is used when possibly to prevent blocking.

The OnDebugExpressionsChanged event is called every time a breakpoint is hit. It is a high volume message and should be used to perform as little work as possible. Off-loading heavy processing to a regulated timer using a flag is highly recommended.

This OnDebugExpressionsChanged event also procides access to the dynamic xml properties from the MicroExtensions.xml config file. Looking up xml poperties is relatively heavy on cpu load as opposed to using class variables to store property settings. For this reason it is recommended that the OnDebugExpressionsChanged event is used to copy regularly used xml config properties into class variables. This will enable functions that are called regularly during a debug session to refer to the class properties and NOT the xml config properties.

When developing .NET visualizations (UserControls and Forms) testing using the slowest possible pc is highly recommended. A good target to aim for seems to be no more than a 3% increase in cpu load on a 1.8Ghz intel processor.

You can easily test the load your extension causes by adding a "Pause" checkbox to your control or form. Stop responding to the OnDebugExpressionValuesChanged event when the checkbox is true. Start a debug session and add a breakpoint that your visualization is watching for intoto the loop().  This causes a huge amount of debug messages to be sent to the pc. Clikcing the Pause checkbox should clearly show in windows task manager the additional cpu load.