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

[JLB88]

Hello people, the VI's work as expected but I'm wondering if there is a performance hit once the project is compiled.

I have 2 versions of a project, one written in LV18 and one in LV21 community edition installed and running on the same computer. It is a media player based on Windows Media Player as an ActiveX control.

(I no longer have access to LV18 so can't compare performance running in development environment)

The LV18 version loads the WMP  "All Music" library and extracts file tags in about 12 seconds, but the same VI in the LV21 version takes about 45 seconds on the same computer.

There is also a similar issue with searching strings in a Multicolumn List. The LV21 version takes around 3 times as long as the LV18 version.

The LV21 version works a lot faster in the development environment but it's hard to get a good comparison

because the development computer's library is 1/10 the size of the target computer's library.

I have spent a lot of time re-writing the LV21 VI's to try and improve things but there is still the performance difference between the development and run time computers. In every other respect the LV21 version performs well on both.

I also wondered whether there may be an issue with having two different run time engines installed on the same computer.

Perhaps there is some other source of the problem I don't know about.

Your thoughts would be appreciated!

Thanks,

Jonathan.

[GerdW]

Hi JLB,

when it comes to benchmarking code then often the benchmarking itself is flawed…

Would you mind to share your code? (I would prefer the LV2018 version.)

---

@JLB88 wrote:

There is also a similar issue with searching strings in a Multicolumn List. The LV21 version takes around 3 times as long as the LV18 version.

---

You should not search "in a MCLB", you should search in an data array used to fill the MCLB…

---

@JLB88 wrote:

I also wondered whether there may be an issue with having two different run time engines installed on the same computer.

---

Usually this is not a problem…

[Yamaeda]

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.

[mcduff]

---

@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.

[Andrey_Dmitriev]

I think it's better to check with a simple benchmark instead of guessing.
Attached is a "stripped down" SHA256 taken from LV2025, downgraded to LV2017 (this is the oldest version I have on hand). All SubVIs are renamed to ensure that exactly this code will be executed under the test and not from vi.lib.

Code:

Results on Intel Xeon W-2245 @ 3.90 GHz:
LV2017 32-bit — 56.6946 MB/s,
LV2025Q1 64-bit — 44.0877 MB/s.
Yes, latest LabVIEW seems to be slightly slower on the given code.

[JLB88]

Thanks for your reply. Taking the MCLB issue, I do get the data  using the "Item Names" property node and process it in array form. Depending on what I'm doing it may be put back into the MCLB once processed. For the benchmarking, see my reply to Andrey_Dmitriev.

[GerdW]

Hi JL,

---

@JLB88 wrote:

Taking the MCLB issue, I do get the data  using the "Item Names" property node and process it in array form. Depending on what I'm doing it may be put back into the MCLB once processed.

---

I don't recommend to use fp elements as data buffer, especially when you need property nodes to access the data! In your case you even try to manipulate MCLB properties instead of MCLB values…

---

@JLB88 wrote:

For the benchmarking, see my reply to Andrey_Dmitriev.

---

Which one?

[JLB88]

Thanks for responding, Andrey_Dmitriev. I'm using the "Take time before and after the code and get the difference" method. It's simple and quite accurate enough for this.

I can't do more than the "Count 1001...1002..." timing method for the LV18 version, it's now a fixed application.

I have been carrying on with playing with the LV21 version looking at the library load issue.

As often happens, I found a significant thing after posting the question. I found some corrupted files in the library of the target computer. The LV18 version happily continues loading them, but the LV21 version hangs for about 6 seconds before continuing on with the next file. Once I deleted them my load time was slashed, but is still slower. I've got a "Progress" indicator which updates every item. I will try making it update less often, see what happens.

[JLB88]

---

I don't recommend to use fp elements as data buffer, especially when you need property nodes to access the data! In your case you even try to manipulate MCLB properties instead of MCLB values

---

Hi GerdW,

I'd be interested to know why you think this is a bad idea, and what alternatives there are. Do you just use the MCLB as user interface and hold the actual data in a FGV, shift register etc? I'm basically self taught at LabView and have always done it this way without any problems, but always keen to learn!

[GerdW]

Hi JLB,

---

@JLB88 wrote:
I'd be interested to know why you think this is a bad idea, and what alternatives there are. Do you just use the MCLB as user interface and hold the actual data in a FGV, shift register etc?

---

• 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"…

I just had a very similar message some days ago…