LV 8.2 Vs. LV 7.1 and large VI file size

[Garraty]

Hi,

I upgraded a large SW developed in LV 7.1 to LV 8.2. After some error corrections I saw that a large Vi in LV 7.1 (a Vi template .vit) that was 18 MB, in LV8.2 was 2.6 MB !

The editing of this Vi is very very very slow, and it's unacceptable. When I save it I can have a coffee break !!

Also, to open the reference to this Vi it's necessary 35-40s but in LV 7.1 2 seconds were enough.

Finally I see also a reduction of the file dimension of some Vi that in LV 7.1 had a large file size (5-8 MB).

Some suggestion about this big-big problem ?

It's possible that LV 8.2 compress (like ZIP) large VI ?

Thanks and regards

[PhillipBrooks]

I guess the question would be "What is in these VIs that allows the compression to reduce the size that much?"

Do you use large (high res) or numerous images on your front panels or block diagrams? Maybe large strings with repeating patterns?

I can't say that I've actually quantified the size change when moving older VIs to 8.0, but the amount of compression seems a bit high.

[Garraty]

Thank you for reply.

In the front panel there is a Digital Waveform Graph that as large dimension..

but, for me, the problem is not the reduced file size. The only one problem is the extreme slowness of the SW in LV8.2

[PhillipBrooks]

The extreme difference in file size indicates that LabVIEW is able to "squeeze" your vi down much more than the typical %50 that ZLIB is capable of. LabVIEW 8.0 introduced compression of the vi. See this LAVA thread. If your VI contains items that are highly compressible, (BMPs, large strings of repeating text?) then the CPU must work more to "enflate" and "deflate" the file when loaded or saved (development environment slower). Your reported values lead me to beleive there is "SOMETHING" in your VI that could be improved.

The other solution is to improve the computer's effeciency; start by cleaning up the hard disk and optimizing it, then upgrade memory, then as a last resort upgrade the CPU. LV 8.2 takes more memory. If your physical RAM is not up to par and if your disk drive is full, you might be paging to disk alot and that would slow you down.

[altenbach]

Filesize is not the issue, it actually got better in 8.20. 🙂 Once the VI is in memory, compression is irrelevant. The main issue is the slowdown and here are a few things to check.

1. Did you actually save the VI in 8.20? (A freshly converted, but not yet saved VI uses significantly more memory and runs slower.)
2. Is your Waveform graph initially empty or did you save the VI with the graph containing large amounts of default data?
3. Does the graph indicator overlap with other elements on the front panel?

Would you mind attaching your VI so I can have a look?

[Garraty]

Good morning and thanks to all.

In my Vi there isn't BMP, large strings.., it's saved in 8.2 format (I coverted and then I saved it), the digital waveform graph is empty initially and there is 2 slide bars that overlap the graph (I update their position when windows resize).

Now I have 2 type of problem:

1-Editing is very slow, and I read other post about the same problem with large vi;

2-Open Vi is very very slow. About this problem I discovered where LV "wait " a lot of time. The Vi is a "clone Vi ", so I open it in the way that you can view in the attached vi. In the Open Vi Refernce block (there is a break point) the CPU work at 100% for a lot of time and , I think, this is the only reason of slowness . After this block, the execution is ok and it's output is:

VI name: READ_DIGITAL 12.vi
VI path:
Application instance: Main Application Instance
Refnum (in hex): 0xCEB00025

[altenbach]

Just curious: Is the VI set to reentrant execution, and if so, why?

[Garraty]

No, it isn't and in the attached image you can view the settings of execution.

There is also another "good "thing about LV 8.2: if there is an error in the Vi (broken wire for example) and I click the Run button, I can't watch the list of error because an error occur and  LV close. To solve this problem I copied all to another new VI...

but the slowness is the worse !

[romulus]

Just wanted to confirm that I'm seeing the same issue with our software. We have a dozen VITs and they all seem to experience this slowdown.