Is there a performance issue with changing VIs to a later LabView version?

[Yamaeda]

---

@mcduff wrote:

---

@Yamaeda wrote:

Generally there's no performance hit in upgrading, but there have been a couple of instances where some specific feature has been bugged. I don't think this is one of those instances though.

---

I have had weird issues with updating to 2024Q3. Below is one example, sorry I cannot share. The case structure has 2 cases, the one not shown is a pass through, just wires across the case structure. In 2024Q3 the Code complexity is more than twice before, whereas, in 2021 I believe it was 2 or lower. Not sure what is going on.

---

Intriguing. Looks like some optimization thing, maybe it unrolls the loop? Is the performance any different?

[mcduff]

---

@Yamaeda wrote:

---

---

Intriguing. Looks like some optimization thing, maybe it unrolls the loop? Is the performance any different?

---

Don't know. I do not have different versions on the same computer to compare. This computer has 2021 installed, the same VI has a code complexity of 0.6, whereas the 2024 version is above 4.

I am guessing that some of the updates are changing parts of the compiler. I have had issues compiling things that I never previously had. Hopefully, it will all be worked out sooner than later.

[JLB88]

---

@GerdW wrote:

---

• Frontpanel (fp) elements are data sources (controls) or data sinks (indicators). They aren't meant to be used as data buffer!
• In the case of (MC)LBs you try to use their properties as data buffer, which adds one more level of obfuscation as you don't even use the value of the fp element as buffer…
• Usually data is held in wires. THINK DATAFLOW!
• Shift registers are great to keep data in loops.
• FGVs are also (kind of) great, I use(d) them a lot. But in the end they are just a "glorified" global variable, which isn't that great when it comes to "clean code architecture"

---

Yes, it makes perfect sense when you put it like that. I'm still developing the project so can make the necessary changes quite easily. Thanks for sharing the benefit of your experience.

[JLB88]

A really strange thing has happened. I deleted the files which were causing the node to wait for 6 seconds then time out. During my fiddling around I restored them to the original folders and the hang/timeout disappeared! And so far has not re-appeared. I just mention it, not even going to try to delve into why. The files are corrupt, and won't play so will be permanently removed anyway.

I've attached a VI which I've written to compare the load times for different ways of generating the data array. If you look at it be warned! It's horrible, rough and ready, and has code which I would not normally use in a "real" VI. If you want to try it, you will need windows media player on your computer and LabView 21 or later. Of the ways I've tried, the fastest is in the "Discrete Elements" case and the "Build/Build Array" case is the slowest. Intriguing that what would probably be considered the worst code performs the fastest, and the best code the slowest!

[Andrey_Dmitriev]

---

@JLB88 wrote:

... the fastest is in the "Discrete Elements" case and the "Build/Build Array" case is the slowest. Intriguing that what would probably be considered the worst code performs the fastest, and the best code the slowest!

---

Of course, Build Array is slowest, this is fully expected result:

On my PC by factor 4.