Can I increase the execution speed of this VI?

[altenbach]

---

@Ben wrote:

---

... and Christian wrote the book on performance.

---

Not really. I am more of an experimentalist. 😄 (or something else that contains the term "mental" 🐵

Without knowing anything about the compiler, we need to resort to testing and benchmarking.

Here are some observations:

• 99% of the benchmarks posted in the forum are flawed and don't prove anything the author is trying to prove.
• Half truths are often misinterpreted and perpetuated. (For example long ago somebody said that local variables are inefficient (they are not!) so some started using value property nodes instead, which are orders of magnitude worse. This is the same logical fallacy exploited by politicians: "If A is bad, B must be good". ... No, B could be worse!!!
• In this case, the term "pre-allocation is more efficient" is misinterpreted as "we need to explicitly pre-allocate to be more efficient". No, explicit pre-allocation is only needed if the compiler cannot know the final array size, but we (the programmer!) actually do. Sometimes we only know an upper size limit, so we can over-allocate and trim at the end.
• Unless we gain at least a factor of two, stick with the simpler and more readable and maintainable code. It is not worth spending half a day to gain a nanosecond in execution time.
• Performance problems are often not due to inefficient algorithm implementation, but due to poor program design (ever-growing data structures, greedy loops, duplication of efforts, UI starvation such as tons of overlapping controls or graphs with gazillions of points).
• Without testing, we cannot predict the best implementation.

[MrJackHamilton]

altenbach,

I'd be interested to know more about the improvements NI has made to Local Variables, pls foward me a link. They've always been bad-mojo,[thank God for sequence locals!]. It's pretty easy for me to pick out C programmers doing LabVIEW. They park all the FP controls to the left neatly, then copiously apply local variables, rinse then repeat!.

The danger of the local var is really the execution order.I recall refactoring a LabVIEW project that collected some promising data. However, it turned out the calculations were not performed in the correct order - due to the author not understanding some pitfalls of 'data-flow', the use of local vars, help aggravate the problem even more. The results from the collected data were not promising..the project was cancelled.

For sanity's sake I don't a lot of code refactoring any more. But I have some very sweet examples of LV diagrams!

I'm a life long fan of LabVIEW, a lot of my clients use it. I try to be open to helping new persons with their code, even if it's a mess!...but it works!..by God!. I try to be very kind when helping them rethink their code, the more LabVIEW converts we have the better off we all are.

Regards

Jack Hamilton

BTY: 10+ years in LV for me...actually going on 30yrs. My first work was in LabVIEW 1.1.2 in Black & White. I still have the 3 1/4 Floppy discs!

[Ben]

Hi Jack,

Please excuse me for jumping in but while we wait for Christian to reply you may want to send some time reviewing the tag clouds I have been developing over the years.

In one of my tag clouds found here there is a link to this post by Christian.

I tried to implement relational tags so that someone can explore the various aspects of LabVIEW by chasing down the various tags.

Some of those tags go back to the day of Greg McKaskle.

I hope that helps!

Ben

[altenbach]

---

MrJackHamilton wrote:

I'd be interested to know more about the improvements NI has made to Local Variables, pls foward me a link. They've always been bad-mojo,[thank God for sequence locals!].

---

If you need to access the same data from several independent location in the code, there is some overhead, but locals are probably quite efficient when compared to other means (queues, notifiers, etc.).

The problem with locals are potential race conditions and code fragmentation (we can no longer tell for sure where the data comes from, how stale it is, and where it is going, for example). They blur the distinction between controls and indicators. You don't want to use locals in tight inner loops in the same way you would not want to place an indicator there, but if you compare the two, the performance is similar.

---

@MrJackHamilton wrote:

[thank God for sequence locals!].

---

My radar is sometimes wrong, but I hope you are joking 😄

[Norbert_B]

---

altenbach wrote:

[...]

---

@MrJackHamilton wrote:

[thank God for sequence locals!].

---

My radar is sometimes wrong, but I hope you are joking 😄

---

Even if not, Jack will see the clear statement regarding stacked sequence structures made by NI by removing them from the palettes with more current LV Versions...... (strong hint: don't use them 😉 )

[sth]

---

@Norbert_B wrote:

---

Even if not, Jack will see the clear statement regarding stacked sequence structures made by NI by removing them from the palettes with more current LV Versions...... (strong hint: don't use them 😉 )

---

Wow, this has drifted a bit.  I use stacked sequences a LOT.  Usually single frames to avoid race conditions etc.  Local variables, value properties etc. are all dangerous for race conditions.  Why are stacked sequences "bad"? 

Unecessary forcing of sequence and slow things down, but that can be both in stacked sequences or in forcing error cluster connections that eliminate parallelism.   But there is nothing inherently wrong with stacked sequences other than hard to read code, but not a performance hit unless they are abused like anything else.

[Norbert_B]

Well, yes, the thread drifted, but still it refers to the topic "execution speed and optimization".

While removing sequence structures from code very often has no significant effect on execution speed performance, specifically removing stacked sequences improves development performance.

The issue is not that a structure by itself is "good" or "bad". It is the style the users are using it. And experience shows that especially the stacked sequence structure is often used in a bad style which obscures and obfuscates code to a very bad level. While this might not affect execution speed (besides: in quite some cases it also slows down executions compared to a well thought out and implemented solution) in the first place, it definitely prevents proper source management (e.g. passing code between developer group members). Stacked sequences compared to flat one make this point specifically urgent as this structure hides code and sequence locals REQUIRE breaking coding guidelines (wires from left to right!).

Using single frame sequences might be OK and sometimes the easiest/best solution (similar to local variables). However, choosing another design of the code could easily remove even those artifacts to get a cleaner code.

Long story short: Chose the best suitable design for your code as such that you manage to remove sequences and variables (local/global) as much as possible. If it is not possible, think about the use case very well (race conditions, ..) and DOCUMENT the use case (ideally with the reason WHY you implemented it like this).

I recommend this not because of your own programming skills in LV but for possible future developer who might inherit your code. If they are not well educated on the data flow paradigm, they see that using sequences and variables is possible, maybe even understand that they are recommend (which they are NOT!). So they start to use these in over-abundance which will very likely start to impact execution speed in a very negative way and of course inducing sporadic errors caused by race conditions.

[JÞB]

---

@sth wrote:

---

@Norbert_B wrote:

---

Even if not, Jack will see the clear statement regarding stacked sequence structures made by NI by removing them from the palettes with more current LV Versions...... (strong hint: don't use them 😉 )

---

Wow, this has drifted a bit.  I use stacked sequences a LOT.  Usually single frames to avoid race conditions etc.  Local variables, value properties etc. are all dangerous for race conditions.  Why are stacked sequences "bad"? 

Unecessary forcing of sequence and slow things down, but that can be both in stacked sequences or in forcing error cluster connections that eliminate parallelism.   But there is nothing inherently wrong with stacked sequences other than hard to read code, but not a performance hit unless they are abused like anything else.

---

There are no inherently wrong structures BUT, there are syntax elements that can be abused.  The Abuse to Use ratio of the SSS is essentially "1"

You can try to argue performance, I once did!  Then CA and I hashed it out Once you get rid of some debugging overhead differences the SSS offers absolutely no benefit and its real shortcomings as opposed to a more scaleable design pattern (i.e. a State Machine) sold me on the truth that the SSS is totally unnecessary to develop quality code in LabVIEW.

To put it another way, Sequence locals are not faster than every other means of passing data, they are simply less debuggable than any of the alternatives!

[MrJackHamilton]

Of course I'm joking...I have not used a sequence structure in at least a decade. They are still good to control order of execution..but mainly because some functions don't have the error cluster.

What is fun, is to open old LabVIEW 4.1 which can run on Windows without an install. And see what 'modern' coding techniques you can pull off!. The USR, the State machine...so awesome.

[sth]

---

@JÞB wrote:

There are no inherently wrong structures BUT, there are syntax elements that can be abused.  The Abuse to Use ratio of the SSS is essentially "1"

---

 I think that was my point.  In general I have been opposed to sequence structures for decades both stacked and flat.  But I would say the Abuse/Use is 1 only if you include the term multi-frame.

The (ab)use of single frame sequences is much much lower.  My point was that lots of flow control can be abused.  The error cluster can force sequentiality unnecessarily as much as any sequence structure.

I think the really bad thing about sequences is the transition from text based programmers who write LabVIEW on a line by line mentality who end up putting each "line" of code in a sequence structure.

The multi-frame sequence structure should be used as much as a GOTO statement.  The only real difference is that "spaghetti code" in LabVIEW actually looks like spaghetti!