Large string array in 6.1 is extremely slow

[Underflow]

Good day all,

While this is in to tech support at NI, I wanted to see if anyone else has encountered it.

I am upgrading from 6.0.2 to 6.1. Several large (2500 rows by 250 columns or larger) string arrays are used as inputs into subvi's. Under 6.0.2, these functions run in tenths of seconds, while under the converted 6.1 vi's they run in 20 seconds or more!

Tracing back using probes, the problem is occurring at the point of the input. It is appears that the array is taking many seconds to copy from the input to the wire on the diagram.

Array controls generated in 6.1 (not converted from 6.0.2) seem to function just fine. Using a save with options... to convert back to 6.0.2, the vi's again function in tenths of
seconds.

Anyone have any ideas?

Thanks!

[mikeporter]

Boy, it sounds like you caught an interesting one! Does it happen with just particular VIs, or can you build a brand new one from scratch, transfer it to 6.1 and it does the same thing?

Also, I'd be curious if you saw the same thing running the converted code on another system. Can you post a simplified version that demonstrates the effect?

Mike...

[Underflow]

Attached are two versions of code: one in 6.0.2, one in 6.1. On my system (650MHz,256 Meg RAM,W2K), the 6.0.2 version loads in perhaps 3 seconds, and runs in around 0.3 seconds, when run in 6.0.2. The 6.1 version loads in around 5 seconds and runs in around 10 seconds.

Tech support got back to me on this one as well. Kudos to the tech support at NI, they are unfailingly courteous and professional. Unfortunately, they say it's a known 6.1 behavior and that I either have to down-rev to 6.0.2, or upgrade to 7.0 to fix the problem :(.

Thanks!

[Underflow]

Some additional testing using a 2500 by 250 string array (times don't include populating the array):

1. Created in 6.0.2, populated in 6.0.2, run in 6.0.2: 0.73 seconds.
2. Created in 6.0.2 (empty), populated in 6.1, run in 6.1: 48 seconds!
3. As 2, but then save with options to 6.0 and run in 6.0.2: 0.73 seconds.
4. Created in 6.1, populated in 6.1, run in 6.1: 34.2 seconds.

Watching some system monitors, it appears memory allocation is MUCH slower in 6.1. It also locks the interface for most of the time the vi is running by monopolizing the processor.

If anyone needs me, I'll be uninstalling 6.1...

[mikeporter]

I did a bit of playing and the same effect doesn't appear to be present with other datatypes. Can you easily restructure your data such that you aren't sending that large an array of strings?

Mike...

[Underflow]

Unfortunately, I'm converting a large number of vi's (2000+ at a guess) from several years of work by multiple developers. I have some doubt in my ability to even *find* all the string array occurences (other than the "wait for something to crash" method), much less convert them to behave differently.

And thanks for your help Mike, your answers and those of others on this board are always appreciated!

[Ben]

I second Underflow's feed-back to Mike.

You are doing some good work here.

Re:the performance issue

Check the defaults for the controls and indicators that are giving you trouble.

LV caries around a default value (somewhere in the background) for all controls and indicators. If the defaults were saved with large strings....

Trying to help

Ben

Go gettem Team!

[mikeporter]

I hear what you're saying about legacy code...

Something you might want to be looking at for the future is migrating to a structure where the data is stored in a 1D array, where each element is a cluster contain the data that's now in a single row. This would be the most straight-forward change, but could make getting at the data tricky, depending on how you need to be able to search it.

Alternately, you could have a cluster containing arrays of each of the row values.In this structure element 0 of all the arrays is the first "row", element 1 of the arrays is the second "row" and so on. This structure at first blush looks more complicated, but it's really not, plus it would allow you to use any value (or combination of
values) to search for a specific row without a lot of parsing.

If the data that is in the example VIs you posted is typical, either of these changes would be advantagous because it looks like there is a lot of reptative data that might be able to be encoded in an enum. Plus storing numbers as numbers often reduces the memory required and produces a predictable memory footprint (an I32 will always take-up 4 bytes per value regardless of how large of small the number is). My sense is that the variability of the string size is what's killing you.

One thing that would make this sort of dramatic change somewhat easier is that because you are changing the basic datatype of the interface, you aren't going to have to worry about finding all the places the change will effect--the wires will be broken.

If you ever decide to take this on, give a hollar.

Mike...

[Alberto]

Hi everybody,
the problem is indeed caused by the huge default value of the array, the behaviour is definitely different between LV6.0.2 and LV6.1, and I don't know why.
What is also strange is that just a little change in the vi followed by a revert causes LV 6.1 to be blocked for several seconds!
Anyway, I've tried to save the array content in a file and read it back in LV6.1, then pass it to a sub-vi as a 2D string array (empty by default) and calculate the size , or whatever. Everything works fine and there is no big difference between LV versions.
So the question is, why do you need to set that value by default?

Alberto

[Underflow]

In the original code, the example vi was a subvi, with no (or a blank, size 0 by 0) default value. The large array was passed in to the subvi, then processed. The behavior as a subvi was identical to having the data as default within the control.

I admit I simplified my example a bit by making the data default within the array, which it normally is not in my code.