LabVIEW Idea Exchange

[#1]

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:

AHHH! What a mess! It's so hard to fit it in, with FP real estate so packed these days!

We need this:

 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.

[#2]

I've thought about this idea for a while (and we've even discussed it within LabVIEW R&D).  This is one of the things I plan implementing as a plugin for the JKI Right-Click Framework (unless they already have it).

-D

[#3]

Ooh, I like it.

[#4]

Hi,

it's already possible with a custom probe. It's a bit circumstantial because you have to know the name of the second probe and insert it into a field in the first probe, but it's already possible. Maybe the name part can be changed (i work on it), but then it should do what you need.

Mike

Message Edited by MikeS81 on 06-16-2009 12:56 PM

[#5]

This is one of the most boring things to have to do and most frequently necessary things to have to carry out.  This is one of the best ideas I've seen on here.  Why isn't it this easy to perform this boring routine task?  Please, NI, implement this ASAP.

Message Edited by InternationAL on 06-16-2009 06:42 AM

[#6]

Just for info. The attached image shows such a custom probe. It needs a lot of time, but it's already possible.

The second probe has to be added directly after the first one. 

Mike

Message Edited by MikeS81 on 06-16-2009 04:21 PM

[#7]

I see problems due to the parallel nature of LabVIEW. Measuring timings like this can be way off, because other code can easily run in parallel and steal cpu cycles from the node under test.

[#8]

I would like this as a build in function. Right click on any node and activate "Timing Measurement". The timing should be sent to a "Timing display window" (which must not be open during runtime nesseccarily). This would give the chance to use a timing below 1 ms.

Even a simple multiply would be of interest when  multiplying an array of CDB with 100,000 elements with another CDB.

[#9]

I would also like to have this little stop watch to spread over the diagram just like a breakpoint.

However I would love to see it at  Tools/Profile/Diagram metrics with some more statistics involved.

A complete matrix might be overkill but nice to select the relations of interest and have last,min,max,mean,sdev and while we are at it: a histogram and export? :-)

And last but not least: the ability to store it (in the vi?) and be able to general enable,disable it. 

Message Edited by Henrik Volkers on 06-27-2009 04:03 PM

[#10]

You could use something like this:

http://decibel.ni.com/content/docs/DOC-6523

It is only 1 ms accuracy but in Windows, you can't really expect much better than that anyways.  Also it requires that one uses error clusters for sequential programming, but this is usually done in most code anyways.  

[#11]

I've taken a similar approach, (also windows-only) but used the performance counter from kernel32.dll.

http://decibel.ni.com/content/docs/DOC-8561

This gives at least 0.1 ms accuracy, I think! (darn overhead)