Time to call sub VIs

[yuta]

I have a problem that sub VIs sometimes spend a time to be called.
I found the problem in my research program, so I made simple VIs to tell it.
I attached an archive file that include test.vi, sub.vi and profile.JPG.
test.vi call sub.vi inside, and profile.JPG is a profile for test.vi.
I'm sorry, it's Japanese version. I'll explain it.
In profile.JPG, sub.vi's average time is 0.0ms, but it's longest time is 15.6ms.
I tried to take some profiles of test.vi, and confirmed that the longest times are every time 15.6ms.
Sub VIs in my research program also spend just 15.6ms.

My PC is Epson Endeavor NT9500pro, CPU is Core Duo and OS is Windows XP SP3.
When I run prime95(ver 25.5, In-place large FFTs and Blend) on background, it also spend just 15.6ms.

I tried to run test.vi on other PCs, {(own PC, Intel Core2Quad Q6700, Windows2000 SP4 on VirtualBox1.6.2 of Ubuntu Linux 8.4.1, LabVIEW 8.6) and (Sharp Mebius MURAMASA PC-MM2-5NE, Efficeon TM8600/1GHz, Windows XP SP3, LabVIEW 8.6)}.
Their longest times are 10ms. This is also every time.
Therefore, this problem isn't caused by slow CPUs and other processes.

I think when programs prepares memories for sub VIs, it takes the time.
If so, I would like to know how to make programs prepare them only on startup time.

Japanese support taught me a solution that unnecessary calculation can be removed by executing sub VIs by event structures only when an input parameter is changed.
Certainly, the solution can avoid the problem in test.vi
However, parameters are every time changed in my research program, so I can't use event structures.

And they taught me the cause might be resolution of LabVIEW profile,
but one PC show 15.6ms, and other PC show 10ms, so it isn't a resolution problem.

I asked Japanese support by e-mails and telephones at first.
They told me that they asked a head office, so I waited.
After 1 week, I got answers, resolution and event structures.
I felt the answers were out of focus, so I asked Japanese support if I can ask the head office directly.
Then he recommended this forum.
Please allow me to ask here by Japanese VI and JPG and my poor English.

[RavensFan]

Please post your attachment as a .zip file.  .tar (and I have no idea what .gz file type is) is an ancient format that nobody ever used anyway.

[altenbach]

There is nothing wrong with gz. Here's the zip version.

[yuta]

Thanks, altenbach.

I comfirmed that contents of question.zip are same as my question20080829.tar.gz.

I'm a Linux user, so I normally use .tar.gz, but I'll use .zip next time.

And I used LabVIEW 8.6 in my question. I forgot  to write the version.

[yuta]

I tried LabVIEW 8.5.1 on my own PC (Intel Core2Quad Q6700, Windows2000 SP4 on VirtualBox1.6.2 of Ubuntu Linux 8.4.1).

Then it also showed the same behavior.

このメッセージは　 09-01-2008 04:34 AM

に yuta が編集しています。

[yuta]

I tried to check times to call sub.vi by Tick Count in test.vi. I attach them as question20080902.zip.

The result is profile20080902.png attached.

In test.vi, Counter is a number of times that are over Threshold.

Then, Counter was 0, but a longest time of sub.vi was 15.6ms.

Why didn't Counter detect the longest time?

[yuta]

I show a profile of my research program as profile_of_research_program.png.

I hid my VIs' names and I added English name of profile data by red letters.

Some VIs' longest time are same 15.6ms.

Some VIs include other VIs whose the time are 15.6ms, but VIs whose Sub VI Time are 0.0ms don't have sub-VIs.

And their VI Time is about an integral multiple of 15.6ms.

46.9/15.6 = 3.0064...

125.0/15.6 = 8.0128...

156.2/15.6 = 10.0128...

31.2/15.6 = 2.0

109.4/15.6 = 7.0128...

62.5/15.6 = 4.0064...

Therefore, it seems that the 15.6ms sometimes occurs and makes delays in my program.

I think this is LabVIEW's bug and it's too fatal.

[Ray.R]

Why do you suspect it is a problem with LV?  How are you measuring the time to access the sub-vi's?  Is the code (in the main VI) leading to the sub-vi calls doing other tasks in parallel up to the sub-vi call?  I'm trying to think of a better way of describing in words what I mean..

I'll try to describe it with an example:

MAIN VI:

Contain a While Loop that does functions-1.

Contains a second while loop that does functions-2 and runs in parallel to functions-1.

Contains other functions and or sub-vi's that run in parallel to the two While Loops.

Inside functions-2, there is a sub-vi call.

Before the sub-vi call within functions-2 (While Loop), there are other VI's doing functions that will pass parameters to the sub-vi.

Everything executes in parallel, between the loops and the function(s) outside the loops).  The CPU executes the last vi before the sub-vi call.  You take a timestamp..  Because there are parallel processes (especially on a single core computer), the CPU does a context switch to the ofther functions handles them (which takes a bit of time), an then returns to the sub-vi in functions-2.  Time has elapsed before the call actually takes place... which is normal..

One way to verify what I am describing is to run your main vi with Highlight Execution turned on and you will see the dynamic events that take place.  Also try to run it several time, because if there are parallel processes, they may not occur in the same order. 

Remember that Labview uses dataflow to determine what executes next.  When data is available, that portion of the code will execute.

Hope the description above helps..

R

[yuta]

I certainly use multi While Loops in my research program, but there is only one While Loop in test.vi shown in profile20080902.png and etc.

Therefore, the problem isn't caused by a parallel processes.

[altenbach]

Let me try to understand your question: so you are worried that sometimes it takes a few ms and sometimes 0ms, and you want a reliable way to always execute the subVI is sub-ms time.

• First of all your benchmarking is flawed, because you also meausure the reading of the FP controls and updating of the FP indicators (2xblue, 2xorange). Updating of indicators is asynchronous, so iterations that include an update will be slower than the others.
• A few ms might well involve an OS task switch or other things out of your control such as cache hits/miss.
• Is debugging enabled?
• What are the priority and thread settings?
• Is the panel of the subVI open or closed?
• Do you really have a REAL performance issue are are you just curious about the somewhat "quantized" values in the profile window?
• I hate to tell you this, but if you are worried about ms jitter, a general purpose OS like windows is not the correct tool. You need LabVIEW RT.