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
Ray.R
Knight of NI

Jack,

 

You're full of great ideas lately.. 😄

 

This one is just "super duper", "dandy"...  what other words could I use?  Ben, can you help me out, here?

😉

Darren
Proven Zealot

I've started using tst's suggestion of the Timed Sequence lately, and it's been more than sufficient for my purposes.  I think the Timed Sequence will solve the majority of use cases for this idea.

tst
Knight of NI Knight of NI
Knight of NI

 


Darren wrote:
I've started using tst's suggestion of the Timed Sequence lately

I haven't. I don't time my code often, but when I do, I have an RCF plugin (which I posted in the RCF group as well) which is easier to use than the timed sequence. The TS takes too long to load and it takes up too much diagram space.

 


___________________
Try to take over the world!
Darren
Proven Zealot

The Timed Sequence only took about 2 seconds to drop on my machine...maybe it's an issue on older computers or LabVIEW versions?  Also, another benefit of the Timed Sequence is how easy it is to remove from the instrumented code once you're done benchmarking.

rgvdh@rdf
Member

A single-frame Timed Sequence will give you exactly the information you want ("iteration duration") as a standard output. 

GregSands
Active Participant

Or use vi.lib/Utility/High Resolution Relative Seconds.vi if you have LV 2010.

Mark_Yedinak
Trusted Enthusiast

If this were a native element in LabVIEW implemented vi something like a breakpoint or probe the manager could easily provide timings for points along the execution path. In addition to the Start/Stop proposed earlier I would add a Lap method. This would be similar to a stop watch so you could not only time an entire process but measures points between as well.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
zenthoef
Active Participant

I'd do this kind of timing analysis a lot more on sections of code with a tool like this. Setting it up with the tick count and case structures can be such a hassle...

Evan P.
Active Participant

Just FYI, a version of these timers do exist in probe form (for error wires currently, could be expaned to many more data types easily).

 

Check out the blog post on my simple, sexy timing probes for more info. These and the statistics probes are used in NI Systems Engineering quite often.



Evan Prothro
RF Systems Engineer | NI

josborne
Active Participant

Darn.  You beat me to it.  I just came here to reccomend this.  A simple timing probe.

 

Basically a quick and easy way to see how long takes to execute certain portions of code.

 

Great idea.

http://www.medicollector.com