LabVIEWs response time during editing becomes so long

MikaelH · March 29, 2010

Hi

Sometimes the response time when editing a large VI gets soooo long.

I can easily see it on the mouse cursor when I move to different object and would expect the cursor to change, but it takes 3-5 second.

Am I the only person to experience this?

I have a powerful PC, so that’s not the bottle neck.

It’s like LV decides to recompile the whole VI and do a complete Error Check of all code in the project.

If I restart LabVIEW it looks like it becomes faster for a short while, then it’s back to be frustrating slow.

So I tried to open my main VI direct, not using the project, and then the response was fast.

I do use lots of classes.

Any ideas?

Have you experienced the same?

Cheers,

Mikael

jdunham · March 29, 2010

I have seen something like this, though I haven't reported it because I can't accurately reproduce it.

I regularly work in LV2009 with an LVProject open which has about 3500 VIs. Usually everything is normal.

When LV gets slow, then often the open windows rearrange their Z-order in the middle of an editing operation, which is very frustrating. Switching from front panel to diagram or changing windows and some editing operations will cause this. On my laptop it can take more than a minute to regain control of LabVIEW, though other applications are not affected (thankfully).

This is much more likely to happen if I have more than one project open. It may also happen if I open an lvlib or an lvclass open in its own window, but I'm not sure.

This also tends to happen if I use ctrl-F in the project window to find a VI, though it doesn't always happen.

Once it starts, the situation does not improve until I restart LabVIEW.

Does this sound like the same problem?

code ferret · March 29, 2010

Hi

Sometimes the response time when editing a large VI gets soooo long.

I can easily see it on the mouse cursor when I move to different object and would expect the cursor to change, but it takes 3-5 second.

Am I the only person to experience this?

Mikael,

I can't speak to your specific problem but no, you are not the only person to experience labview slowness. I am using 2009 SP1 and not only is it slow, but it is a little unstable. I frequently encounter strange problems that require not merely a labview restart, but a reboot - particularly regarding RT tools.

ned · March 30, 2010

When LV gets slow, then often the open windows rearrange their Z-order in the middle of an editing operation, which is very frustrating. Switching from front panel to diagram or changing windows and some editing operations will cause this. On my laptop it can take more than a minute to regain control of LabVIEW, though other applications are not affected (thankfully).

I see something like this regularly, and as far as I've been able to tell in my case it seems to be a combination of using classes, and storing everything on a network drive. Whenever I see LabVIEW lock up temporarily my network usage also goes up (according to the Windows task manager), as though LabVIEW is reloading a lot of files from disk at once, which it might do more frequently when using OOP classes for some reason.

PJM_labview · March 30, 2010

Hi

Sometimes the response time when editing a large VI gets soooo long.

I can easily see it on the mouse cursor when I move to different object and would expect the cursor to change, but it takes 3-5 second.

Am I the only person to experience this?

I have a powerful PC, so that’s not the bottle neck.

It’s like LV decides to recompile the whole VI and do a complete Error Check of all code in the project.

If I restart LabVIEW it looks like it becomes faster for a short while, then it’s back to be frustrating slow.

So I tried to open my main VI direct, not using the project, and then the response was fast.

I do use lots of classes.

Any ideas?

Have you experienced the same?

Cheers,

Mikael

I am seeing something very similar in my project as well (although restarting LV do NOT help me at all). Thankfully in my case I do not (yet) have to wait 3-5s but more like 1-2s.

I also use a lot of classes (both by val and by ref) and there are over 3K VIs in that project.

When I have this project open and I do an edit in a VI I see the hour class between each edit.

Like you I also have a fast computer.

My workaround, at the moment, is to no longer use my full project (unless I have to) but to only open the class I want to edit (resulting in less stuff in memory) and this way everything is back to normal.

When LV gets slow, then often the open windows rearrange their Z-order in the middle of an editing operation, which is very frustrating. Switching from front panel to diagram or changing windows and some editing operations will cause this. On my laptop it can take more than a minute to regain control of LabVIEW, though other applications are not affected (thankfully).

I am also seeing this as well. It does sometimes resolve itself (meaning I regain control of LabVIEW) but not always. I have situation where I try to drop a node from a palette or create a property nodes and LV get in that mode and it never recover (no matter how long I wait). I then have to restart LV, open the project, create a blank VI, create the nodes I want in the blank VI and then copy then from the blank VI to the VI I want them to be (if I try again directly in the target VI, LV hangs again). Pretty painful.

Oh, and another things I am seeing is LV crashing when probing wire with large cluster (like the one you got in a large state machine).

Note: I do not have any network drive involve in this.

Note: All of this happen with LV 2009 f2.

PJM

MikaelH · March 30, 2010

Thanks Guys

It’s always nice to see that I’m not alone out there

I’m using 8.6.1, and also lvlib’s containing classes.

I would guess it has something to do with Dependencies or Error Checking.

I’m keen on creating a big dummy projects and submitting it to NI to see if they can figure something out.

If they managed to find a solution for LV2010, I promise I’ll be the first to upgrade ;-)

Cheers,

Mikael

MikaelH · May 21, 2010

I'm updating this topic, since it bugs me so much that I can't have the Project Explorer open while editing my larger VIs.

I just looked at my Quad Core CPU usages when I just added a simple DBL wired to an ADD-node

What is causing the Project Explorer to use so much resource?

//Mikael

jgcode · May 21, 2010

When LV gets slow, then often the open windows rearrange their Z-order in the middle of an editing operation, which is very frustrating. Switching from front panel to diagram or changing windows and some editing operations will cause this. On my laptop it can take more than a minute to regain control of LabVIEW, though other applications are not affected (thankfully).

That one really annoys me!

I'm updating this topic, since it bugs me so much that I can't have the Project Explorer open while editing my larger VIs.

I just looked at my Quad Core CPU usages when I just added a simple DBL wired to an ADD-node

What is causing the Project Explorer to use so much resource?

//Mikael

Damn that is nothing! - anyone here do FPGA?

Check this out:

I also:

Use a lot of Classes and Libraries

Use Integrated SCC with the LabVIEW Project

Often use multiple targets

All which slows it waaaay down....

I would like to add up all the time during a day with which I get the spinning blue circle of death.

I think it would be quite significant.

Maybe we need a LabVIEW Project support group?

I'll start: "Hi my name is JG, I am addicted to using the LabVIEW Project, even tho I know its really bad for me....."

MikaelH · May 21, 2010

I'm about to

Damn that is nothing! - anyone here do FPGA?

Check this out:

BTW have you tried not using the Project Explorer for the FPGA development, is it faster then ?

//Mikael

jgcode · May 21, 2010

I'm about to

I know exactly how you feel!

I love LabVIEW but it can be slow and prone to so many crashes!

Especially I find from using Classes and Libraries!

Then you have to reboot it, and I have/need all the modules installed so that takes ages on my (mid-level) PC.

Then I have to solve the complex time algorithm of: Do I load the palettes at startup or wait until I activate Quick Drop?

BTW have you tried not using the Project Explorer for the FPGA development, is it faster then ?

As far as I know you can't really, its tied in too heavily to the Project.

All the target info and access to the modules/IO nodes, config adding hardware etc... come from the Project

I have never tried it but I am guessing no tho.

As I am pretty sure you would need the target in memory and be working from it or LabVIEW wouldn't have a clue your target is RT or FPGA and not just a PC - so all the RT or FPGA specific stuff would break and you probably would be able to access it from the palette.

But like I said, I have never tried...

...maybe I will later just to see...

Djed · May 25, 2010

If you have large projects open and are doing editing of large VIs, you may want to turn autosave off. Autosave, which I believe is on by default, results in a compile and therefore a full error check every few minutes. If you are good about saving periodically, I would recommend considering this; it may help.

Omar Mussa · May 25, 2010

I have seen LabVIEW slowdown, 2009 SP1 does not seem to fix any of the bottlenecks for me. I have seen the >3 sec edit times as well.

Here are some things that I think contribute to slow development edits (note: these have major impacts on my ability to develop code quickly using LabVIEW -- also note, I typically have the lvproj file open and I know opening the code without lvproj file open helps this somewhat but it disrupts other parts of my development flow a lot as well)

1) Dynamic dispatched methods -- when I first started using classes in LV 8.2 I thought the ideal default behavior for classes would be to enable dyn. dispatching. I've since changed my mind and now try to minimize dyn. dispatching due to edit time performance hits.

2) Tab controls -- I've noticed that if I have a tab control with 'a lot' (not quantified) of controls and indicators, that LabVIEW edits get really slow. I think having a lot of controls/indicators in general may be an issue, but I have seen real issues when editing tab controls (this has happened on multiple projects in LV 8.5, 8.6 and 2009 for me).

3) Large number of VIs in project. I'd say that once you are over 2000 VIs you probably experience some pain and over 3000 VIs definitely puts my development virtual machine into slow motion (strangely, it really affects some VIs more than others and I'm not sure what causes that except for possibly items 1 & 2 above). Also, despite the really awesome potential power of having multiple project files open, I find that I generally can only have 1 project open or I get major edit time performance impacts due to context synchronization -- especially when the projects point to the same code (for example reuse libraries).

4) One of the things that has actually crashed LabVIEW for me and is really annoying is editing/applying type definition changes. I think LabVIEW has a workflow issue in that every edit to a type-def causes LabVIEW to try to figure out what VIs are now in an unsaved state even before you've hit 'apply typedef changes' or saved the type-def. This makes edits on typedefs pretty painful and can make applying type defs a finger crossing experience for me. I've noticed that there are a few cases that seem to be really problematic -- 1: editing a typedef that is used by a class but is not a member of the lvclass (happens when I create a new type-def from a control that is used by a lvclass method) 2: trying to add a type-def to a lvclass when the lvclass already uses the typedef. Somehow, these operations do not seem very stable in LV2009 SP1 for me (or in previous versions).

I haven't filed any of these as bug reports with NI due to lack of time, lack of reproducibility and lack of my ability to create a 3000 VI project that I can share with NI.

PaulG. · May 25, 2010

Check this out:

Just watching the video was bad enough. If I had to work with a system that bogged down I would be insane by now.

jgcode · May 26, 2010

Just watching the video was bad enough. If I had to work with a system that bogged down I would be insane by now.

Yep, we already have two FPGA programmers shipped off to the asylum!

jgcode · May 26, 2010

1) Dynamic dispatched methods -- when I first started using classes in LV 8.2 I thought the ideal default behavior for classes would be to enable dyn. dispatching. I've since changed my mind and now try to minimize dyn. dispatching due to edit time performance hits.

Hi Omar

Me too - because the default when I was learning seemed to be DD so I made everything DD!

Now I use Static, but more so as I don't want to expose overrides unless I really need them (from an exposure/scope POV).

If you noticed performance hits that good news too.

4) One of the things that has actually crashed LabVIEW for me and is really annoying is editing/applying type definition changes. I think LabVIEW has a workflow issue in that every edit to a type-def causes LabVIEW to try to figure out what VIs are now in an unsaved state even before you've hit 'apply typedef changes' or saved the type-def. This makes edits on typedefs pretty painful and can make applying type defs a finger crossing experience for me. I've noticed that there are a few cases that seem to be really problematic -- 1: editing a typedef that is used by a class but is not a member of the lvclass (happens when I create a new type-def from a control that is used by a lvclass method) 2: trying to add a type-def to a lvclass when the lvclass already uses the typedef. Somehow, these operations do not seem very stable in LV2009 SP1 for me (or in previous versions).

Oh boy! This one drives me crazy, I am so used to it know though that I can normally pick when it is going to happen.

I find any editing of the Class Control can cause this behaviour e.g. adding a normal path or numeric control etc...

I wish they would fix this up.

If they need a reason for it, they should call it a "feature" so they can talk about it at NI Week.

I would rather this over most other new features, because I don't like going through the pain of rebooting, loading the palettes etc.. as that is where I get major-ly slowed down. This could easily happen 10+ times a day.

My workaround, at the moment, is to no longer use my full project (unless I have to) but to only open the class I want to edit (resulting in less stuff in memory) and this way everything is back to normal.

Hi PJM

Do you save these .lvproj files with your main project?

I.e. do you have a .lvproj file that contains a Class (or maybe related classes) and its Test VIs etc... that you work for.

Or you have more of a dynamic workflow where you pull the Class you want to work into a new .lvproj file and don't save that .lvproj file when you are done?

If you have large projects open and are doing editing of large VIs, you may want to turn autosave off. Autosave, which I believe is on by default, results in a compile and therefore a full error check every few minutes. If you are good about saving periodically, I would recommend considering this; it may help.

Hi Djed

Thanks for the tip - I will give this a go.

***

Cheers

-JG

MikaelH · May 26, 2010

I haven't filed any of these as bug reports with NI due to lack of time, lack of reproducibility and lack of my ability to create a 3000 VI project that I can share with NI.

I've sent this issue direct to one of the LabVIEW Developers to have a look at.

Of cause they are a bit busy right now...but I'll keep you posted on the progress.

FYI

The Autosave doesn’t fix my problem.

I use tons of Typedefs, most of them belonging to classes.

Many of my application are using Tab with lots and controls on then, so that could be a problem.

But it's still fast when editing it without the project windows open.

So it has to be something to do with the project window, I would guess the Dependencies or similar.

Cheers,

Mikael

Daklu · July 9, 2010

Of cause they are a bit busy right now...but I'll keep you posted on the progress.

Floating this thread to find out if anyone has been able to narrow down a cause or find a resolution.

pravinspidy · July 12, 2010

I've sent this issue direct to one of the LabVIEW Developers to have a look at.

Of cause they are a bit busy right now...but I'll keep you posted on the progress.

FYI

The Autosave doesn’t fix my problem.

I use tons of Typedefs, most of them belonging to classes.

Many of my application are using Tab with lots and controls on then, so that could be a problem.

But it's still fast when editing it without the project windows open.

So it has to be something to do with the project window, I would guess the Dependencies or similar.

Cheers,

Mikael

hi MikaelH,

i have faced a same problem in my project.... but my application is quite different from urs

i am using lot of numerical controls & displays in my vi nearly(600 controls) so i want to connect so many wires & i am communicating the controls via com port.... i have faced problems while editing when i trieb to connect some controls i takes 30 secs to one min i can able to see in mouse pointer.... me too using a good effective pc.... i thought the problem is with my system ram i upgraded to 2gb still i am facing this problem.....

but the problem is solved for me by creating a subvi for every 20 controls it optimized the code & there i didn find any hang up while editing........... :rolleyes:

MikaelH · July 12, 2010

Did you try to open the VI (when it was slow), without the project explorer?

My issue is definitely tied into the usage of the Project window.

Cheers,

Mikael

MikaelH · July 12, 2010

I thought that the GDS Project Window Explorer hooks caused the delay in editing, but I’m now trying without GDS activated, and now it takes 15 seconds for LV to response for a simple edit, and when I now press Ctrl-Z it takes >30 seconds and of cause reordering the windows in Z-position.

BTW my project file is about 870kB, is that a lot?

Does anyone know if it's possible to disable the Conflict Checking in the project?

//Mikael

MikaelH · July 26, 2010

Good news

This issue should be resolved in LV2010...and I guess it's only a couple of days left :rolleyes:

//Mike

Djed · August 2, 2010

On that note, LV R&D is collecting info to further improve edit-time responsiveness. We'd appreciate everyone who has the time to fill out this survey: http://bit.ly/aWBf1j

Daklu · August 3, 2010

On that note, LV R&D is collecting info to further improve edit-time responsiveness. We'd appreciate everyone who has the time to fill out this survey: http://bit.ly/aWBf1j

So each question has three rating categories. "Frequency" and "Today's Performance" are self-explanatory, but I have not idea what "Expected Work" is supposed to mean. Is that how much work we expect NI to put into that feature?

jgcode · August 3, 2010

So each question has three rating categories. "Frequency" and "Today's Performance" are self-explanatory, but I have not idea what "Expected Work" is supposed to mean. Is that how much work we expect NI to put into that feature?

I took that as my future expected work with that feature???

Good to see they are taking data on this.

Darren · August 3, 2010

So each question has three rating categories. "Frequency" and "Today's Performance" are self-explanatory, but I have not idea what "Expected Work" is supposed to mean. Is that how much work we expect NI to put into that feature?

I believe it's asking how much time you're willing to give LabVIEW to perform the action. For example, a frequent editor action, like wiring two terminals, you would expect to be a "trivial" amount of work, i.e. LabVIEW should be able to perform the action immediately. But for something else, like building an EXE, you would probably expect LabVIEW to spend more time, and be ok with that.

I don't particularly like how that option is worded, but that's my understanding of what it's supposed to mean.

-D

LabVIEWs response time during editing becomes so long

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Join the conversation

Important Information