Measuring Execution Times

[MikaelH]

Hi guys

How do you measure execution times/performance?

I have 3 favourites.

The Profiler (Profile Performance and Memory)

Desktop Execution Trace toolkit (it give um timing accuracy very nice )

And a Timing Probe (see attached VIs)

How do you do it?

Timing Probe (Error).vi

TimingProbe_Kernel.vi

Cheers,

Mike

[Grampa_of_Oliva_n_Eden]

I avoid construct that kill time like the plague so it has been a while since I had to do benchmarks on code perfomance (it problably has more to do with faster CPUs than my imporved coiding techniques I freely admit) but when I did I used the seq frame with ms tick counts.

But, I kept performance in mind as I have been developing and buried in the "top-level" Hardware Class (from which most of my widgets inherit) there is an optional built-in timing functions so I can turn on the time logging functions. I hope I never have to use them!

Ben

[Ulf]

Hi,

Another question, how do you measure the "CPU-usage" in a VI?

Regards

Ulf

[Mellroth]

I just learned about this little guy at NI-Week this year,

I have only tested it briefly so far, but I believe you get us resolution with this as well.

/J

[Tim_S]

Hi,

Another question, how do you measure the "CPU-usage" in a VI?

Task manager gives a general idea. The Tools->Profile->Performance and Memory menu option gives a good idea of where that CPU time is going.

Tim

[MikaelH]

Another question, how do you measure the "CPU-usage" in a VI?

Ulf, try the Desktop Execution Trace toolkit, it gives you info which CPU runs which VI.

I just learned about this little guy at NI-Week this year,

I have only tested it briefly so far, but I believe you get us resolution with this as well.

/J

Cool I'll give it a try.

//Mike

[Ulf]

Mikael,

Does the "Desktop Execution Trace Toolkit" give information about CPU-load? I can only see the CPU Id... Found a nice GUI-bug, although, in the toolkit when I expanded it to full-screeen on a "vertical" display. I seems like the toolkit is built in LabVIEW.... You can see a "local" 1D-array of enums in the left down corner of the application.

//Ulf

[MikaelH]

Does the "Desktop Execution Trace Toolkit" give information about CPU-load?

No not what I know about.

I seems like the toolkit is built in LabVIEW

Your right, and it's very impressing LV application, it's written in LV 8.6 :-)

Cheers,

Mike

[Mark Balla]

I just learned about this little guy at NI-Week this year,

I have only tested it briefly so far, but I believe you get us resolution with this as well.

/J

I wouldn't rely on it too much.

There is a reason it is not in the pallet

I remember this issue being discussed previously.

From this simple test vi I built you can see that it is very inconsistent compared to the other methods.

I am curious to know what NI Week session discussed this vi.

My guess is that is is designed for RT targets.

Mark

[drjdpowell]

From this simple test vi I built you can see that it is very inconsistent compared to the other methods.

The other two methods aren't precise enough to see the <0.5ms variation in times. The ms timer can only time to the millisecond, and the datetime is even less accurate.

[Samapico]

The other two methods aren't precise enough to see the <0.5ms variation in times. The ms timer can only time to the millisecond, and the datetime is even less accurate.

Yeah... take a look at the attached image. The datetime makes you think it's accurate by showing a bunch of decimals, but it still has a ~1ms resolution.

The example you posted actually proves that the high res timer IS way more accurate. More accurate than the wait(ms) VI anyway

Edit: Using the same kind of code, the resolution of the high res timer is about ~0.31106 microseconds,

or 3.1106 E-7 seconds.

Pretty cool, imo.

Edited September 1, 2011 by Samapico

[asbo]

Yeah... take a look at the attached image. The datetime makes you think it's accurate by showing a bunch of decimals, but it still has a ~1ms resolution.

I think that's just a double hard at work

[Samapico]

I don't think a double would have problems with these decimals, but the date/time might be using singles internally... But yeah

[Mellroth]

I am curious to know what NI Week session discussed this vi.

My guess is that is is designed for RT targets.

I'm sure it wasn't one of the RT sessions, instead I believe it was a tips and trick session with Darren.

/J

[rob.dye]

I came here looking to see what the G experts have done wrt timing probes and found this discussion of High Resolution Relative Seconds.vi (HRRS).

I am the person responsible for putting this VI in vi.lib/Utility. It calls back into a utility function I put into LV, which uses the same API that is used by the Desktop Execution Trace Toolkit. I intended it to use the highest resolution clock available on all of LabVIEW's supported platforms. On Windows this means QueryPerformanceCounter, which, in modern versions of Windows, takes into account multi-core/processor issues as well as variations in clock rate due to power management. (Up to date and authoritative docs on this are hard to find, but from the googling I've done, I believe my claim is correct.) This

I discuss some of the behavior of HRRS at this site at ni.com:

https://decibel.ni.com/content/blogs/EvanP/2010/10/04/tick-count-us--microsecond-timing-granularity-on-windows

(I notice some of the picture links are busted there - I'll try to fix them.)

As some of you noted, the Wait (ms) primitive is the inaccurate/inconsistent culprit in the Mr. Balla's benchmark. It uses a less accurate clock API, but one that uses the same clock as the "Get Date/Time in Seconds" and "Tick Count (ms)" primitives.

Rob Dye

LabVIEW R&D

[Darren]

I didn't realize you were the one who added that VI, Rob. I've recommended it in multple performance presentations over the past couple of years, and your comments here and on the ni.com thread give me some extra details to include the next time I discuss it. Thanks!

[MikaelH]

High Resolution Relative Seconds.vi (HRRS).

I am the person responsible for putting this VI in vi.lib/Utility.

Thanks for that VI, I love it.

I even made my own Wait (us), VI with that and it works great.

[asbo]

Thanks for that VI, I love it.

I even made my own Wait (us), VI with that and it works great.

That's awesome.

So, when will something like that be shipping with LabVIEW?

[ShaunR]

It's a shame that the conditional disable structure cannot tell what version of LabVIEW it is. I've got a "Tick Count" vi that uses the perf counter method on windows, the normal (1ms) one on the others and it would be great if I could put another case in there to use this little gem for when I'm working in 2010 and greater so it uses the best available (I have to work in 2009,10 and 11).

[Stagg54]

It's a shame that the conditional disable structure cannot tell what version of LabVIEW it is. I've got a "Tick Count" vi that uses the perf counter method on windows, the normal (1ms) one on the others and it would be great if I could put another case in there to use this little gem for when I'm working in 2010 and greater so it uses the best available (I have to work in 2009,10 and 11).

Sounds like something for the idea exchange.

[pravinspidy]

Hi guys How do you measure execution times/performance? I have 3 favourites. The Profiler (Profile Performance and Memory) Desktop Execution Trace toolkit (it give um timing accuracy very nice ) And a Timing Probe (see attached VIs) How do you do it? Timing Probe (Error).vi TimingProbe_Kernel.vi Cheers, Mike

informative !!!! thanks