LabVIEW

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

Community Nugget 05/27/2009

Highlighted

On occasion, you may wish to measure the amount of time a certain piece of code takes to execute.

 

What many people do is something like one of these options:

 

Timer.png

 

But this annoying to rewrite every time. If you're good, you probably have a merge VI or use VIs such as the OpenG VIs shown here to save some time on writing this code.

 

 

Well, there is a faster way:

 

Timer2.png

 

 

The timed sequence has an output terminal which tells you how long it takes to execute. You can simply drop one and select that terminal.

 

Caveats:

  1. I believe they're only available on Windows and RT.
  2. They take too much space (but then, so does the alternative).
  3. If you're running your code in parallel with other code (which you should not be doing), they might get higher priority, thus skewing the results. I don't know enough about this to give a good answer.
  4. When you drop one, it has terminals on the inside. You have to select to hide them if you don't want them.

 

For a list of past nuggets, see here.

 


___________________
Try to take over the world!
Message 1 of 9
(3,666 Views)

Some minor bugs:

* We already have the year 2010 

* In the first pic (flat sequence), the inputs of the substract-prim needs to be swapped (as in the code using OpenG)

 

Anyway, thanks for the community nugget.

 

Felix 

0 Kudos
Message 2 of 9
(3,649 Views)

F. Schubert wrote:
We already have the year 2010 

Do we? Well, what can I say, I'm a retro kind of guy.

 


In the first pic (flat sequence), the inputs of the substract-prim needs to be swapped (as in the code using OpenG)


Actually, in both cases the earlier time is correctly substracted from the later time. It's just arranged differently (and I agree it can be confusing. Another reason to do this, although personally I don't time my code very often, so I don't actually use this).

___________________
Try to take over the world!
0 Kudos
Message 3 of 9
(3,608 Views)

 

 



In the first pic (flat sequence), the inputs of the substract-prim needs to be swapped (as in the code using OpenG)


Actually, in both cases the earlier time is correctly substracted from the later time. It's just arranged differently (and I agree it can be confusing. Another reason to do this, although personally I don't time my code very often, so I don't actually use this).


 :robotsurprised:

 

 

Sequences always make me nervous...:robotmad:

 

 

So I prefer negative times for two reasons:

* Something odd is on my BD

* Rewind the time ASAP before the moment I dropped the sequence

 :robotvery-happy:

 

Felix

0 Kudos
Message 4 of 9
(3,543 Views)
Neat idea tst. I do that all the time (first method) but now I'll save time, thanks.
Message Edited by Broken Arrow on 05-27-2010 04:17 PM
Richard






0 Kudos
Message 5 of 9
(3,515 Views)
Also, if your code takes more than 50 days to execute, the tick count method won't work. The timed sequence method should be good for ~300 million years Smiley Wink

___________________
Try to take over the world!
0 Kudos
Message 6 of 9
(3,414 Views)

Nice trick. I'm not sure if it is as accurate, but I usually use a custom probe to accomplish this. That way you can do timing checks without changing your code. My version keeps track of your worst timing cycle.

 

 TimeProbe_howto.png

 

I have attached the error cluster version of the probe that you are free to use. You will need to create a new version for different data types. All probes use the same notifier to communicate, so you can use two probes of different data types to time a single operation.

 

do you think this is a good way to accomplish this?

 

 

Message 7 of 9
(3,209 Views)
Hi bazookazuz!  I think that looks pretty neat and will give it a try.  I'll try it with some of my code and compare it to the results of the methods tst has posted.  My first thought I had when trying to do some code timing was: "Shouldn't there be a probe for this or something?"
0 Kudos
Message 8 of 9
(3,191 Views)

I forgot to metion the probe method because I was focusing on getting that off my mind.

 

You are correct that the probe method has a great advantage in that you don't need to change the code, but it also has some disadvantages:

  1. If you're trying to measure a block of code, a single entry and exit point may not be enough. A structure clearly defines multiple dataflow paths as a single unit.
  2. If you're timing something, it's often because you need performance. I haven't checked, but using a probe might affect that (although usually if you're measuring performance, you do an average of N runs and so the timing code runs only before and after, so it shouldn't matter).
  3. If you want to time more than one area of the code, the probe won't allow you to do that unless you start explicitly pairing probes or adding code which will remember their order.
All that said, I don't time my code that often, so I usually don't even remember the timed sequence trick and resort to the classic 3-frame-sequence or OpenG timers.

___________________
Try to take over the world!
0 Kudos
Message 9 of 9
(3,153 Views)