LabVIEW 2010 slow vi save performance

[Kevin.Shirey]

So when will loading, saving and compiling take advantage of multiple cores and cpu's? It appears all loading, saving and compiling only use one core of one cpu.

[Yndigegn]

Its been almost a year since the severe performance issue handling large VI's were solved.

And I am happy to report that LabVIEW 2010 SP1 is one of the all time great version of LabVIEW. It just keeps running on our 30 productions computer without any issues whatsoever. And developing in 2010 SP1 has also been without issues in the time passed since that release.

A Happy New Year to all

[StudioGuy]

Agreed -- the "fix" in SP1 was a good decision, and 2011 continues well.

Always encouraging to have a responsive vendor like NI.

Best to all.

[rrawer]

It seems to me that lv2010sp1 as well as lv2011 use multiple cores but it does not use hyper threading (of the 8 logical cores of my core i 7 only every second is used)
In addition the speed increase between a core 2 duo 8400 win xp raid 1 hd system and a core i7 win 7 64bit everything installed on a fast ssd was only anout factor 2 i would say and neither the harddrive nor the cpu it really working hard during saving - it seems the system is more waiting for timeouts then actually working.
Hence the original problem when saving large vis is bettet then before but compared to lv 7.5.1 all the 20xx versions take much longer ( i would say a factor 2 to 5)
I' m usong lv2010 and 2011 mow but i'm still waiting for a erformace inrease during save and compile...

Rainer

[nonecure]

I didn’t read this entire post, so sorry if I say something that has already been said.  I had a lot of issues with this and found that a SSD that has a high number of I/O read/writes per second makes a big difference.  It seems that on saves, it does many small reads and writes to the drive.  So many SSD’s can R/W huge files fast, you need one has had a higher IOPS rating.

The other thing is, this might be NI’s way to force everyone to have small vi’s.

[rrawer]

I have a revodive 2 with brchmarked 95000 iopd so I guess that should do. I think its still the same problem that you need to build slim vis with the new labview versions otherwise saving and compiling takes for ever.
But as I said before it seems to me that the compiling and saving process is using only about 15% of the availlable computing power and I'm sure it's not restricted by the io rate of the ssd either. I'm hoping fore some further increase of compile performance in the near future...

[nonecure]

Wow, nice SSD;  mine has IOPS of ~50k.

I agree with you 100% that something needs done with the save performance.  It is hard for me to write small vi’s when my machine has 8 stations and test 4 parts at each station with 2 full racks of analog cards.  It has been a problem ever since I upgraded from LV 8.6.  Buying the fastest PC I could get was not good enough; I still had to spend weeks on slimming down the main vi just to make saves more tolerable.

[rrawer]

Exactly that's the point. I also thought cpu power and a really fast ssd could do the job but was really disapointed...)
I was also hoping that someone would point out a syle guide for integrating large event handlers (lets say 50 to 100 event cases) into the main vi and still have a chance for reasonably fast save time...

[Mountain_Matt]

I ran into this problem recently as my program has grown in size.  At first I noticed the program taking over one minute to compile, then a month or so later, the compile is taking over 2 minutes.  My ADD just doesn't allow me to sit patiently for that long, and I always end up getting distracted by something else before the compile is complete.  Faced with the prospect of shelling out over $3000 for SPI1 (Labview's fix), I looked for other solutions.

Turns out the biggest memory draws were Property Nodes I had used for things like enabling/disabling Controls, making Controls visible/invisible and so forth.  I use quite a few arrays, but I've been using individual propery nodes for each element in the array.  I won't go into what a pain in the @$$ this can be.

By reducing the number of Property Nodes, I was able to reduce my compile time from 2-1/2 minutes down to 12 seconds. : )

Matt

[altenbach]

---

Mountain_Matt wrote:

Turns out the biggest memory draws were Property Nodes I had used for things like enabling/disabling Controls, making Controls visible/invisible and so forth.  I use quite a few arrays, but I've been using individual propery nodes for each element in the array.  I won't go into what a pain in the @$$ this can be.

---

How exactly were you modifying enable/disable or visible/invisible properties of individual array elements. That simply does not sound right, because all elements of an array share their properties, except for the value.