Jump to content

Measuring Execution Times


Recommended Posts

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! :rolleyes:

Ben

Link to comment

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,

post-5958-0-02633600-1314798251_thumb.pn

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

Link to comment

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

Link to comment

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

post-5958-0-02633600-1314798251_thumb.pn

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.

post-584-0-43053900-1314881021_thumb.png

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

My guess is that is is designed for RT targets.

Mark

Link to comment

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 :P

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.

post-25044-0-09056500-1314885819_thumb.p

Edited by Samapico
Link to comment
  • 10 months later...

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!

Link to comment

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

  • Like 1
Link to comment
  • 4 weeks later...

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.

Link to comment
  • 2 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.