why is programming in Labview 8.2 so terribly slow

[Ben]

I supose I spend to much time watching the task manager but....

Since the big difference between editing from the project and not is the .proj file. Since the .proj is a standard file format, I wonder how much the anti-virus programs are playing in this slow performance.

Just a thought....

Ben

[johan_W]

Dear Rolf,

Thanks for your explanation of the problems that might raise from using the Global variables. I'm indeed more a programmer of quick and dirty lab applications and than the global variables are easy to use. 

[peterlowrie]

You'll probably notice this problem more on Windows than in Linux. I'm sorry to say that I too have found this difficulty on my Windows box but when opening and working on the vi in Linux (dual boot) it worked just fine.

[Ben]

"You'll probably notice this problem more on Windows than in Linux."

and yet another reason to suspect the virus checking.

Ben

[xlAutomation]

I have no anti-virus software running at the moment. I recently removed McAfee because it is supremely annoying.

To recap, note that the extremely slow response I am experiencing in block diagram editor

1) only occurs when opening the VI from a project

2) occurs regardless of the number of shared variables or even local or global variables. I initially had NO shared variables in the project (immediately after upgrading from 7.1) and had slow response, and even then, I had a very reasonable number of globals (maybe 10 or so) in the project.

Michael

[rolfk]

---

@xlAutomation wrote:

I have no anti-virus software running at the moment. I recently removed McAfee because it is supremely annoying.

To recap, note that the extremely slow response I am experiencing in block diagram editor

1) only occurs when opening the VI from a project

2) occurs regardless of the number of shared variables or even local or global variables. I initially had NO shared variables in the project (immediately after upgrading from 7.1) and had slow response, and even then, I had a very reasonable number of globals (maybe 10 or so) in the project.

Michael

---

Normal globals should definitely not have much of an influence on the edit performance but can have for the runtime performance. One other case like that I once had after inheriting a LabVIEW 6.1 application was that the original programmer had written a main VI with about 10 case structures that were put inside another sequence frame with three of the case structures with much over 100 frames each. The VI was reasonably ok in runtime performance but moving a single wire took seconds. The fact that everything was passed by globals didn't help the whole case both for runtime performance as wel as understanding and debugging the application..

I redesigned the application, got rid of the 3 biggest case structures by putting them first in separate subVIs, cleaned up wires to go as straight as possible instead of making 10 roundabouts over the diagram before going to the destination and also replaced quite some globals through LV2 style globals and the edit performance got about linearly better as I reduced by this the number of wire sgements. And that is not so strange since LabVIEW does a syntax and consistency check while you are wiring so having a very huge (this single main VI was over 10MB on disk) is bound to cause the LabVIEW syntax checker to require some time.

Rolf Kalbermatter

[dwisti]

While I agree with rolfk that passing data around using shared variables is poor data flow.  However, you can create a shared variable and enable the real-time FIFO to deterministically share data to a time-critical vi.  I'm experiencing this same delay while editing VIs with numerous shared variables on the block diagram.  This is a bug and should get fixed for development of real-time targets.  Are there any updates on CAR# 4388O1FI?

David

[ChrisRP]

We are working to fix the slow edit time when a diagram contains lots of Shared Variables.  Unfortunately, the fix will not be ready in time for the next LabVIEW release.  We do realize that this is a major issue with Shared Variables, and we will continue to work on the solution.

Until we can finish the solution, you can avoid the slow edit time performance by placing your Shared Variable nodes inside subVIs and calling those subVIs to read from or write to the Shared Variables.  Once you have moved the Shared Variables into subVIs, you will notice a significant improvement in the time that it takes to perform editing operations on your main VI.  If you have an existing VI that contains Shared Variable nodes, there is an easy way to move them into subVIs.  Click the Shared Variable node on the diagram to select it, and then choose “Create SubVI” from the Edit menu.  LabVIEW will automatically move the Shared Variable node to a new subVI, add any wired inputs and outputs to the connector pane, drop the new subVI on your diagram, and wire the inputs and outputs.  If you encounter any issues with the execution of your application after you have applied this workaround, try making the subVIs reentrant. Please let me know if you have questions about implementing this workaround. ChrisRP
LabVIEW R&D

[dwisti]

ChrisRP,
Thanks for the workaround.  Since its going to be two releases of Labview away, I will start wrapping my shared variables into subvi's.  On a side note, this size of shared variables is klunky anyway.  I really wish there was a shared variable node like a vi server property node. That way would be perfect when using a cluster bundle/unbundle node.  Also, the naming convention on the labels should be "." based like bundle/unbundle nodes (i.e. Target.Library.Shared Variable) with the ability to hide full names.  I guess I should submit a feature request.

David

[geirove]

Hello,

I have seen the same behavior in 8.2: When VI's are opened from the Project Explorer things start taking a lot of time. When working with Real Time projects (e.g. cFP) you got to open VI's through the Project Explorer, so there is even no workaround.

Also, if using the State Diagram Toolkot., State Highlighting (for debuggin) does NOT work when the VI's are opened through the Project Explorer, making this kind of debugging impossible in our Compact FieldPoint project  😞 We have reported this bug, but it is still around !