slow f labview 2011

[instrumento]

For better of for worse (don't ask me to change it now, we will, later) we store lots of data on front panel controls that are arrays of very large clusters.

When we load this code with LabVIEW 7.1 on Windows XP 32 bit, core 2 quad machine, the code is already a bit slow and it is targeted to be replaced, eventually.

Just tried the same thing with LabVIEW 2011, on Windows 7, 64 bit, i7 quad machine, and the speed of the code, is, how should I say, a bit underwhelming.  After several minutes I killed LabVIEW as I thought it was stuck.  Molasses comes to mind!  Is there a setting I can tweak?  This is a no go...

[MoReese]

Your system is spending all it's time updating the front panel because of the poor design.  To optimize, it depends on what your updating and how often, but it sounds like you are in serious need of redesign.

[RavensFan]

I'd say that if you are making such a big jump from 7.1 to 2011, now is the perfect time (not later) to fix all the things that are broken with your design.

[instrumento]

Let me see if I got this right...

I've upgraded from Windows XP to Windows 7.
I've upgraded from a 32 bit OS to a 64 bit OS.
I've upgraded from a dual core duo/quad CPU to an i7 quad.
I've upgraded from LabVIEW 7.1 to LabVIEW 2011.
I had LV 2011 recompile all my VIs.
A function that took about 30s now takes several minutes, so many that I gave up waiting.
And the recommendation is to redesign my application?

As Mrs. Palin said, "You betcha I will."
But I tell you one thing, it won't be in LabVIEW.

[MoReese]

---

@instrumento wrote:

For better of for worse (don't ask me to change it now, we will, later) we store lots of data on front panel controls that are arrays of very large clusters.

When we load this code with LabVIEW 7.1 on Windows XP 32 bit, core 2 quad machine, the code is already a bit slow and it is targeted to be replaced, eventually.

Just tried the same thing with LabVIEW 2011, on Windows 7, 64 bit, i7 quad machine, and the speed of the code, is, how should I say, a bit underwhelming.  After several minutes I killed LabVIEW as I thought it was stuck.  Molasses comes to mind!  Is there a setting I can tweak?  This is a no go...

---

By your own admission, or at least you suspect, the program has a poor design.  Don't blame Labview for the poor choice of the programmer.  LabView is just the tool used to do the job.  I would give you the same advise regardless of which language it was written in.  You can rewrite it in any language you wish, but until you or others programming practices change, you will repeat the same mistakes.  It sounds like lack of training...another poor choice for those just starting out with LabView.  Frankly, we have just given you some friendly advise.  I don't give a d*** whether you fix it or not.

[instrumento]

Read what I said.  The new machine can run laps around the old one and the same poor or not so poor program runs 20 to 50 times slower with a newer version of LabVIEW.  Seems to me the problem lays with whatever changed within LabVIEW. I should probably just install LV 7.1 on that machine and run like that while I migrate to a more sane environment.

[MoReese]

Although you saw a better response with the other version (30 seconds is still too long), this program is probably still a good candidate for redesign.  You yourself said it would be changed...later.  That's fine, but I agree with Ravens Fan.  Now, with the upgrade, would be a good time to fix those design issues.  It's a good learning experience (although it hurts a bit).

[instrumento]

We're loading a lot of data from a database and filling clusters with it.  Maybe who coded that routine 5 or 6 years ago didn't do the best job but it has been working fine, i.e not a problem; 30 secs is acceptable on tests that run from 1 to 6 hours (there's lot of chip probing (vision aided), running current sweeps and current sweeps, fiber aligment, re-alignment, etc, etc.)  but upwards of 10 minutes to load that data just because we're running a new version of LabVIEW isn't.

Our environment comprises over 3000 VIs, some small, some large, a few DLLs, changing it isn't easy, again, just because LV changed. And I'm not being stubborn and not listening, I already said that I will redesign 🙂 a few posts back.

[Jim_K]

Just curious, what would be a better design?

I haven't tried making a front panel that has an array of clusters on it, simply because I don't have an application with that much information to display. I have an application that has a cluster of controls and indicators, and it works fine in LabVIEW 2010 SP1,

I find it odd that the application takes 30 seconds to update the screen in LabVIEW 7.1, but takes many minutes in LabVIEW 2011. If it were me, I would open a technical support request with NI.

[instrumento]

We really don't want to display any of that info 🙂  We just want to fill arrays of clusters that we then pass around.  Data comes in from Oracle and needs to end up in those arrays of clusters.  We have several of those types of clusters and fill them in in a generic fashion, no dedicated one routine per cluster type, as long as all the controls in the clusters are strings, values (or arrays of those).  The routine that does that fills in a cluster that is stored in the front panel and needs to be visible (can't be hidden) or the data won't make it there.  It redimensions the array for the number rows that we get from oracle (again variable) and fills each control in the cluster.

Probably there is a better way to do that, but so far it hasn't been a problem so no one looked at it, we have a lot of non-programming work to do around here, and all the programming for new tests. I've been painstainkly bringing our code into LV2011, branched all the code in our revision control system, and people are still changing the mainline, which in a graphical language like LV will make for a lot of pain when I have to merge the new changes.  I was unpleasantly surprised when that code is now a terrible bottleneck.  I sincerely thought the code had crashed due to some incompatibiity and was suprised when one set of data (there's about 7 of those coming from oracle) of 334 rows of 54 data points just set there spinning and spinning filling the cluster.

All I was expecting here was, make sure you set this or that, which is new in LV 2011.  I don't need people to tell me that I should redesign my code, but it is sad when I have to do that to adapt to what is in effect a new compiler.