cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

FOR loop + Case structure to accommodate indicators in small space - performance?

Solved!
Go to solution

Re: FOR loop + Case structure to accommodate indicators in small space - performance?


@Blokk wrote:

@altenbach wrote:

... 


This triggered an idea for a new structure, the "parallel stack". It would look like a stacked sequence, but would simply instruct the compiler to do all frames in no particular order and as parallel as possible. :D It would be just a cosmetic diagram organization tool and would be treated as if all frames were flattened out to the diagram. Smiley Very Happy Hmmm....


If you put this on the idea exchange, i will vote for it! Smiley Happy


Brace yourself for the questions coming from text coders converting to LV and not being able to figure out why that structure is not determining execution order...

 

Ben

0 Kudos
Message 11 of 19
(169 Views)

Re: FOR loop + Case structure to accommodate indicators in small space - performance?

Well, if you set parallelism for a FOR loop, it neither defines a deterministic order... right?

0 Kudos
Message 12 of 19
(167 Views)

Re: FOR loop + Case structure to accommodate indicators in small space - performance?


@Blokk wrote:

Well, if you set parallelism for a FOR loop, it neither defines a deterministic order... right?


Correct!

 

Ben

0 Kudos
Message 13 of 19
(163 Views)

Re: FOR loop + Case structure to accommodate indicators in small space - performance?


@altenbach wrote:

This triggered an idea for a new structure, the "parallel stack". It would look like a stacked sequence, but would simply instruct the compiler to do all frames in no particular order and as parallel as possible. Smiley Very Happy It would be just a cosmetic diagram organization tool and would be treated as if all frames were flattened out to the diagram. Smiley Very Happy Hmmm....

 

Frames could be freely named according to function and clicking would expose a pulldown with all frame names for direct access.


Already in the Idea Exchange: Parallel Execution Structure as opposed to Sequence Structure


There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 14 of 19
(159 Views)

Re: FOR loop + Case structure to accommodate indicators in small space - performance?

Thanks. I was posting by phone and could not search efficiently.  (I vaguely remembered something with diagram tabs).


LabVIEW Champion Do more with less code and in less time
0 Kudos
Message 15 of 19
(156 Views)

Re: FOR loop + Case structure to accommodate indicators in small space - performance?


@altenbach wrote:

I agree with Ben that you won't notice an impact, these are just scalars. Updating the UI thread is asynchronous anyway.


The discussion spawned an extra question, and I am interested in your opinion people. So, I have also a time stamp indicator and a special custom boolean indicator besides the already mentioned numeric indicators (the boolean indicator is just a custom one with a "floppy disk" symbol on the True, and the False is set to invisible; when file rec is ongoing, this indicator is negated at every iteration to show a blinking floppy symbol).

 

Ok, because by default all the indicators are set to "Asynchronous display", I notice sometimes a tiny jitter in the Time stamp indicator (the seconds are not "equidistant"), and in the "blinking" of the Boolean one. This hurts my OCD a bit. Note, I measure the While loop iteration time, it is tightly 1000 msec.

 

Question: in such cases (like for Time stamp indicators), when we want to show nice tight synchronous display update to the user, should we just use the "Synchronous display" setting? Would this bite back, I imagine at this scale not? I just realized, I NEVER ever used this Sync display setting activated for any of my indicators since I program in LabVIEW. That is why I ask, what is the common practice here? Thanks! Smiley Happy

0 Kudos
Message 16 of 19
(123 Views)

Re: FOR loop + Case structure to accommodate indicators in small space - performance?


@Blokk wrote:
Ok, because by default all the indicators are set to "Asynchronous display", I notice sometimes a tiny jitter in the Time stamp indicator (the seconds are not "equidistant"), and in the "blinking" of the Boolean one. This hurts my OCD a bit. Note, I measure the While loop iteration time, it is tightly 1000 msec.

 


 

If the loop rate is 1000ms, I would think that the flashing should be quite regular unless you are really starving the UI thread. This can happen for example if you set one of the high priorities for the VIs, so make sure to leave it at "normal". It probably can also occur if a lot of things are happening in the UI thread (unsafe DLLs, property nodes, graphs with lots of data, etc. )

I sometimes see hesitations right after a VI is loaded (by double-clicking in explorer with LabVIEW initially closed) and run right away, probably because a lot of things are still executing in the background (e.g. loading of palettes, etc.). These things normalize quickly.

 

I am not 100% sure what the update rate of the UI thread is, but it is probably close to the typical refresh rate of the monitor. Synchronous display will slow down your code dramatically. Try a synchronous indicator in a tight loop. The difference will be many orders of magnitude. I never use it.


LabVIEW Champion Do more with less code and in less time
0 Kudos
Message 17 of 19
(112 Views)

Re: FOR loop + Case structure to accommodate indicators in small space - performance?


@altenbach wrote:

@Blokk wrote:
Ok, because by default all the indicators are set to "Asynchronous display", I notice sometimes a tiny jitter in the Time stamp indicator (the seconds are not "equidistant"), and in the "blinking" of the Boolean one. This hurts my OCD a bit. Note, I measure the While loop iteration time, it is tightly 1000 msec.

 


 

If the loop rate is 1000ms, I would think that the flashing should be quite regular unless you are really starving the UI thread. This can happen for example if you set one of the high priorities for the VIs, so make sure to leave it at "normal". It probably can also occur if a lot of things are happening in the UI thread (unsafe DLLs, property nodes, graphs with lots of data, etc. )

I sometimes see hesitations right after a VI is loaded (by double-clicking in explorer with LabVIEW initially closed) and run right away, probably because a lot of things are still executing in the background (e.g. loading of palettes, etc.). These things normalize quickly.

 

I am not 100% sure what the update rate of the UI thread is, but it is probably close to the typical refresh rate of the monitor. Synchronous display will slow down your code dramatically. Try a synchronous indicator in a tight loop. The difference will be many orders of magnitude. I never use it.


I run the application as a built exe. We use a somewhat older laptop, i guess it has an Intel i3 CPU, and i upgraded it's RAM to 8GB. OS is Win 7 x64. I more often see this jitter when I take the laptop out from screen saver mode (sleep mode is disabled).

 

Thanks for the advices about these settings!

0 Kudos
Message 18 of 19
(106 Views)

Re: FOR loop + Case structure to accommodate indicators in small space - performance?

I concur with the UI Thread suspicions.

 

If you want it to flash regular then it should be in its own loop and the indicator updated "synchronously".

 

G-Story that lead to me pushing the get the answer I posted in the "Duct Tape Required" thread.

 

I had an application that spawned off a background process to fetch updates from a bunch of FieldPoint units running LV RT. The fetching made use of a VI served Action Engine served by the FieldPoint units in order to realize hand-shaking that prevented any potential loss of historical data.

 

Elsewhere in the application, I had a picture ring that was incremented to present an animated indicator that showed network traffic was taking place.

 

All worked as I expected until the application was brought back-up after the PC had been shutdown. The animation would stall for long periods even though the network traffic was happening as it should. It turned out the heavy use of VI server and massive amounts of history data being fetched the UI thread was being swamped.

 

So...

 

Suspect the UI thread.

 

Ben

Message 19 of 19
(81 Views)