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
Enrique
Active Participant

Very nice suggestion. They way I was visualizing it is that when you right-click a VI or a piece of code that is enclosed (like inside a for-loop or a sequence), you have the option of a timing probe. Then that piece of code is highlighted similar to a break and you will see a small probe window.adding_timer.PNG


 

 

with_timer.PNG

www.vartortech.com
JÞB
Knight of NI

As long as we are talking about a quick benchmarking method lets go one step further.  While timing probes are in memory automatically disable Automatic error handeling and debugging. Smiley Surprised


"Should be" isn't "Is" -Jay
shb
Active Participant
Active Participant

VI Box Probes from Saphir also contains timing probes (named chronograph). I really like them.

Install the package with VIPM or see first http://sine.ni.com/nips/cds/view/p/lang/de/nid/209756

Jokelnice
Active Participant

When can we see such ideas implemented?.



Ing. Jonathan E. Cruz Ortiz

ENERGÍA PROACTIVA S.A.S

Cel : (+57) 3173669343 - (+57) 3124451894

thutch79
Active Participant

I had the same idea, though I was thinking of it in a structure sense. I like the probe idea, but I thought maybe something similar to a case structure. You wrap it around the code you want to test. It has an output of time (ms). This would be a little more powerful in that you could time things executing in a loop and get all the times out. Probes would certainly be less invasive. The structure would just be a simplier representation of the same code we all use to test execution time today.

crossrulz
Knight of NI

thutch, I'm pretty sure you can do all of that with the Timed Loop Structure


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Darren
Proven Zealot
Status changed to: 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.

DavidGrimm
Member

Like tic toc in matlab