LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
JackDunaway

Allow a quick "Timing Probe" for Timing Metrics

Status: Declined

National Instruments will not be implementing this idea. LabVIEW R&D has researched the concept of a quick timing probe and concluded that, for a variety of reasons, it would be difficult to provide a robust "quick" solution. One of the primary reasons involves difficulty in determining when timestamps are gathered. Timestamps gathered at the moment of probe execution happen when upstream nodes generate the data, NOT when downstream nodes consume them. This can lead to confusion about what is being timed. For instance, if a user is trying to time a node by putting a Timing Probe on an input wire and an output wire, it is possible that the Timing Probe on the input wire executes before other inputs are ready. The resulting delta between that input wire and the output wire may be longer than the time that the node consumed.

 

LabVIEW R&D continues to research this issue, and we are exploring multiple alternative solutions, including:

  • Node Probes, where you have a single probe that not only displays all the inputs and outputs of a given node, but also provides timing information of the node
  • Additional infrastructure within the probe mechanism itself whereby you can get information like the delta t between executions of any probes that have been created

For now, please see this forum post on Data-agnostic Smart Probes, which is a feature of LabVIEW 2016 and later that facilitates the implementation of a quick timing probe. Note that we have posted an example Timing Probe to that thread.

Typical question in development process: "How quickly does my code execute? What runs faster... Code A or Code B?" So, if you're like me, you throw in a quick sequence that looks like this:

 

TimingDuringDevelopment.png

 

AHHH! What a mess! It's so hard to fit it in, with FP real estate so packed these days!

 

We need this:

ProposedTimingDuringDevelopment.png

 Just like my other idea, and for simplicity's sake NI, I would be PERFECTLY happy even if you had to set up the probes during edit mode, and were not able to "probe" while running.

 

 As a bonus, this idea may be extrapolated into n timing probes, where you can find delta t between any two of the probes.

29 Comments
Darren
Proven Zealot

I've thought about this idea for a while (and we've even discussed it within LabVIEW R&D).  This is one of the things I plan implementing as a plugin for the JKI Right-Click Framework (unless they already have it).

 

-D

Intaris
Proven Zealot
Ooh, I like it.
MikeS81
Proven Zealot

Hi,

it's already possible with a custom probe. It's a bit circumstantial because you have to know the name of the second probe and insert it into a field in the first probe, but it's already possible. Maybe the name part can be changed (i work on it), but then it should do what you need.

 

Mike

Message Edited by MikeS81 on 06-16-2009 12:56 PM
InternationAL
Member
This is one of the most boring things to have to do and most frequently necessary things to have to carry out.  This is one of the best ideas I've seen on here.  Why isn't it this easy to perform this boring routine task?  Please, NI, implement this ASAP.
Message Edited by InternationAL on 06-16-2009 06:42 AM
MikeS81
Proven Zealot

Just for info. The attached image shows such a custom probe. It needs a lot of time, but it's already possible.

The second probe has to be added directly after the first one. 

 

Probe.PNG

 

Mike

Message Edited by MikeS81 on 06-16-2009 04:21 PM
altenbach
Knight of NI
I see problems due to the parallel nature of LabVIEW. Measuring timings like this can be way off, because other code can easily run in parallel and steal cpu cycles from the node under test.
waldemar.hersacher
Active Participant

I would like this as a build in function. Right click on any node and activate "Timing Measurement". The timing should be sent to a "Timing display window" (which must not be open during runtime nesseccarily). This would give the chance to use a timing below 1 ms.

Even a simple multiply would be of interest when  multiplying an array of CDB with 100,000 elements with another CDB.

Waldemar

Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions
Henrik_Volkers
Trusted Enthusiast

I would also like to have this little stop watch to spread over the diagram just like a breakpoint.

However I would love to see it at  Tools/Profile/Diagram metrics with some more statistics involved.

A complete matrix might be overkill but nice to select the relations of interest and have last,min,max,mean,sdev and while we are at it: a histogram and export? 🙂

And last but not least: the ability to store it (in the vi?) and be able to general enable,disable it. 

 

 

 

Message Edited by Henrik Volkers on 06-27-2009 04:03 PM
Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


David_L
Active Participant

You could use something like this:

http://decibel.ni.com/content/docs/DOC-6523

 

It is only 1 ms accuracy but in Windows, you can't really expect much better than that anyways.  Also it requires that one uses error clusters for sequential programming, but this is usually done in most code anyways.  

RandyP
Member

I've taken a similar approach, (also windows-only) but used the performance counter from kernel32.dll.

 

http://decibel.ni.com/content/docs/DOC-8561

 

This gives at least 0.1 ms accuracy, I think! (darn overhead)
-Randy
-=--=-=-=-=-=-=-
Nothing like a good dose of LabVIEW to cure what ails ya'.