Community Nugget 05/27/2009

[tst]

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:

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:

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.

[F._Schubert]

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 

[tst]

---

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).

[F._Schubert]

---

---

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).

---

 

Sequences always make me nervous...

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

 

Felix

[Broken_Arrow]

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

[tst]

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 😉

[soupy]

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.

 

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?

[hecmar.arreola]

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?"

[tst]

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.