Labiew wire is very slow

[Yamaeda]

So how can you find these crazy objects? Do VI analyzer help or is it just trial and error?

(And how do i quote thing on the forum, there used to be a button for that ...)

/Y

[GerdW]

Hi Yamaeda,

---

@Yamaeda wrote:

And how do i quote thing on the forum, there used to be a button for that ...

---

See here:

[thols]

---

@Yamaeda wrote:

So how can you find these crazy objects? Do VI analyzer help or is it just trial and error?

(And how do i quote thing on the forum, there used to be a button for that ...)

/Y

---

The insane objects are discussed here, with some tips and links. But that can get a bit advanced.

Yamaeda, quote using the quote-button 🙂

[ericyuan]

That's a good suggestion, yes, i edit the code in a project, I will have a try to edit that main.vi by only open it without open a whole project,

[ericyuan]

I think it's a structure's problem, But  i actually didnot have any heavy task in that if case, only two layer if case. 

So feel strange when faced with this problem

[wiebe@CARYA]

---

@ericyuan wrote:

I think it's a structure's problem, But  i actually didnot have any heavy task in that if case, only two layer if case. 

So feel strange when faced with this problem

---

The editor doesn't care about how heavy a task is (during execution).

It can be about complexity of the wiring. Insane objects used to happen a lot with type defs (mainly enums and clusters) that where resizing when edited. This would misalign the anchor point of the wire to the node...

What seems like a heavy task to you, might be easy for the editor. And vice versa.

One simple wire could be corrupted some way, making a simple case diagram slow to edit...

[Bob_Schor]

There are a lot of very experienced LabVIEW Users on this Forum.  We could help you much more directly if you do the following steps:

• Compress the folder that contains the LabVIEW Project that is "slow to edit".  You should get a .zip file with the contents of the Folder.
• Attach your VIs (meaning the .zip file containing the entire Project) to your response.

Doing this will serve several purposes:

• We can determine which version of LabVIEW you are using.
• We can see if you are doing things "very inefficiently", and can suggest (and actually try out!) changes to speed things up.
• If there is a "problem for Experts", the Experts will be able to look at the problem and probably provide you with a solution.

Bob Schor

[crossrulz]

When I see edit time slow downs, it is almost always due to "Compiled Code Complexity" getting too high.  You can look at the number in the VI Properties under the Memory Usage category.  If you are getting above 7 or 8, issues will start.  You can reduce the complexity with subVIs and/or better algorithms (remove duplicate code).  Inline VIs will also add to the complexity.  If you can't do anything to reduce that, then you can go into the LabVIEW options (Tools->Options) under the Environment category and play around with the Compiler Optimization settings to limit the optimizations the compiler does.

[Ben]

Ditto the idea of trying to edit with the project closed. There was an issue a couple of versions back that was involved with the project and classes (I do not recall the details but something about reevaluating from the top down vs the bottom up or some such).

Also make sure the auto-populating folders is turned OFF. That will slow down the IDE.

Ben

[wiebe@CARYA]

---

@Bob_Schor wrote:

• Attach your VIs (meaning the .zip file containing the entire Project) to your response.

---

That is unlikely to happen, as even the names of the cases in the screenshot are obfuscated.

I don't think there's much else we can do without the code...