LabVIEW 8.5 is slow when editing

[gnunesjr]

I just converted one of my pet projects to version 8.5 from 8.0. 

I find that the editor is all of a sudden extremely slow.  I can't so much as draw a single wire without the hourglass popping up for a second or two at the end of it.  Under 8.0, I never noticed any delay after such a small edit.

I have not changed my project in any large way.  I only was making a very minor tweak, so that cannot be the issue.

I'm running on a Dell laptop, 2 GHz, 2GB.  It is the same laptop as yesterday, so no change there.

My main VI is about 3.5 MB, and it calls about 150 sub-VIs.  None of this has been changed.

Is this a "known" problem?  I searched this forum, but could find nobody else complaining of an editing performance change in going from 8.0 to 8.5.  In fact, a few folks seemed to notice things going the other way (8.5 faster at dropping in a VI than 8.0).

Based on one of the posted comments, I tried opening the main VI directly instead of opening the project manager and opening it through that.  I could not detect any difference.

I've been using 8.5 for a couple of months, but only on very tiny VIs, and found the editing to be just fine.  Tonight is the first time I've taken the plunge and converted one of my larger projects.

Any help would be appreciated, as the current situation is rather painful.

[Britoa]

3.5MB? How do you manage to fit all that on one screen?  One of my biggest VIs is around 400k, and that's even quite high.  Do you need to call all 150 SubVIs from the main VI?  (If I misunderstood this point, sorry)  The VI I mentioned is the main VI in a project of around 1200, but I am not calling them all from the top.  Could you layer it a bit more, to clear up the top-level?

I have a feeling your slowdown problem is due to a huge VI.

[Ray.R]

I agree with Britoa..

My complete projects are usually less than 2 MB.  And those are considered large projects. 

3.5 MB for a single vi seems astronomical!  😮  Wow..  Does the block diagram fit within a single screen on your PC?

Can you post the code?

RayR

[Ben]

VI's with fancy graphic can be that large.

I suggest (after you backup your code ) that you make sure all of your VI's are saved as version 8.5.

If you don't have fancy graphics then check to make sure you don't have large data structures that have been saved as defaults.

ANd if these guesses don't help, please tell us more about the VI making special note of any stuff you are doing in this VI that you are not doing in the little ones you mentioned.

Trying to help,

Ben

[gnunesjr]

Perhaps you have missed the point.  Editing my VI is not slow because it is large.  Editing my VI is slow because I switched to version 8.5.  Anyone care to address that particular issue?

(I don't know why the VI is large, except that it does a lot.  It controls a very complicated instrument involving motion control, microscopy, image acquisition, and image processing.  And I have to say, without being obnoxious about it, that it has done this job beautifully and without major issues, up until "upgrading" to 8.5.  There are large sections of code, maybe as much as 20 to 30% that are in triplicate, as I support multiple versions running on slightly different hardware.  I control which version is active through project conditional disable symbols.  This works very nicely, but the duplicated code lives in the VI, making it larger than it's true running size.

And no, I don't call all 150 VIs from the top VI!  Some sub VIs call other sub VIs, and so on, in the usual way.  If this was a large C or FORTRAN project, and I said there were a total of 150 subroutines and functions, nobody would bat an eye.  Why should that be and issue with LabVIEW?

It is true that I can't fit the block diagram on one screen.  The program has 5 event loops running in parallel.  Each event loop is mostly independent and is responsible for a single physical subsystem in my instrument.  I just move between them by horizontal scrolling, which I will admit can get a bit tedious.

And....before every expert on this list trys to jump down my throat, I did spend over a month re-writing the code to a "better" model:  a single producer loop with a single consumer loop.  Despite considerable effort, this model never ran as well or was as responsive to the user interface as my "obviously incorrect" approach.  LV appears to be unbelievably efficient in managing parallel loops, so I'm going with that.  You can argue the point, and I will agree that you are correct in principle, and that I possibly could have beaten the consumer/producer version to the point where it worked as well as the parallel loop version.  But, since I already had a version that worked that well, and pressure to move on to the next project, I had no incentive to keep at it.

Sorry.  The code is considered proprietary (whether worthy of such protectio nor not!), so I can't post it.  Besides, you don't really want to look at it.  Trust me.)

[Ray.R]

---

gnunesjr wrote:

And no, I don't call all 150 VIs from the top VI!  Some sub VIs call other sub VIs, and so on, in the usual way.  If this was a large C or FORTRAN project, and I said there were a total of 150 subroutines and functions, nobody would bat an eye.  Why should that be and issue with LabVIEW?

---

Actually, having 150 vi's is not an issue.  Anything that is considered a function and can be standalone and reused is well to be implemented as its own vi (or sub-vi).

After upgrading to LV8.5, did you do a Mass Compile?  I don't recall having seen speed issues when going up with LV versions, including 8.5.  Not while editing code..

RayR

[gnunesjr]

Ray-

I had not done a mass compile.  Thanks for that tip.  Unfortunately, that does not help the problem.

Just to confirm, I opened up a backup copy of my project under 8.0.  I deleted a wire, and re-drew it.  I got the hourglass for about 0.5 sec following the draw.  Under 8.5, re-drawing the same wire takes ~2 sec.

-Geoff

[Ray.R]

... interesting...  drawing a wire should not be that slow..

Curious:  what was the wire between?  What are the two objects being wired?

RayR

[gnunesjr]

I get the same performance for all wires:  between one of my sub VIs and a concatenate string function, between a T/F constant and a while-loop control, between a local variable and a cluster unbundle...  It really doesn't matter.  Dragging things around on the screen, popping up a palette and selecting a function, dropping in a case structure, adding a case to a case structure.... everything is slow.  I get the same performance whether at home, where I am using the built-in graphics and my XGA laptop screen, or docked at work, where I use a fancy graphics adapter with dual 1280 X 1024 monitors.

[pallen]

It wasn't completely clear from your posts; Do you get the same editing performance problems with this project on different physical systems?

I once had on of my LV installations become "corrupt" in some way, and ended up with symptoms much like you're describing.  I would try to connect something with a wire and editor would "freeze" for short moments.  Eventually I could get some editing done.  But it was painful. 

In my case it was my LV installation that was messed up.  Not my project.  Re-installing after MSI Blast cleared it up.