The Desktop Execution Trace Toolkit (DETT) collects hundreds to thousands of data points that indicate memory allocations, queue references, events, and more. The data is always available and often is overwhelming. The only way to make sense of data quickly is to create custom probes that create highlights in the data, however, that is only after you know which VI is worth probing further.
The idea:
Feed all the data normally collected by the DETT about a LabVIEW project directly into Nigel so that it can provide human-friendly suggestions explaining:
Level 1
How often a VI allocates memory in a repeated fashion
The time jitter between different events
VI's that could be good candidates for refactoring
Level 2
Improvements to the code within that VI based on best practices for optimal compiler operations.
This is based off a discussion at GDevCon #6 on September 10th, 2025.
George T. of Thetic Engineering Ltd.
Consulting in the UK on Test Strategy with TestStand, LabVIEW, NI STS, PXI, and Python
