LabVIEW 8.6.1 Project causes slow Open VI Reference

[Gleichman]

I have an odd problem with "Open VI Reference.vi".

Case 1.

• Open  LabVIEW project containing "Main.vi"
• Open "Main.vi"
• Run "Main.vi"
• Execution of "Open VI Reference.vi" take about 2,000ms

Case 2.

• Open "Main.vi" - No LabVIEW project open
• Run "Main.vi"
• Execution of "Open VI Reference.vi" take about 100ms

I converted the project to 8.5 and the problem goes away. I don't have any machines with 8.6.0 to test if this is an issue with 8.6.1 only.

Has anybody else seen something like this?

[smercurio_fc]

Can you upload the project and its files so that others can try it in 8.6.0? If not, can you create a small example that shows the problem?

[Gleichman]

I converted this project to LabVIEW 2009 and I still have the same issue.

[Gleichman]

I have reproduced the problem and found additional clues. I've attached a zip file containing two projects. Project "load close time - small" contains only the six files relevent files. Project "load close time" contains these files and a folder snapshot of vi.lib\gmath. I added this folder strictly for the purpose to make the project larger. Here are the execution times on my computer:

"load close time.vi" - no project: 26 ms

"load close time.vi" - "Load time - small" project: 82 ms

"load close time.vi" - "Load time" project: 852 ms

VIs are in LV2009

Message Edited by Gleichman on 08-21-2009 02:43 PM

[smercurio_fc]

Your VIs are not runnable because you did not include typedefs. Also, not everyone has the OpenG functions.

Did your project in 8.5/8.6 have the gmath library? If not, I fail to see what this shows other than a long loading time for the project, which is completely expected. 

[Gleichman]

Good catch on the type def. It turns out that this is also key to the problem.  I cleaned up my example VIs, removed the Type Defs and OpenG VIs. When I ran the cleaned up VIs the problem went away. So, I added a simple type def back to my called VI and the problem was back.

You misunderstand the reason for including gmath into the project. This has nothing to do with the time to load the project from disk. The problem is slow execution of "Open VI Reference.vi" when opening VIs that contain TypeDefs that are in large projects. By including gmath I was able to create a large project without attaching extra VIs.

Open Reference Test - No Project: 11 ms

Open Reference Test - small Project: 105 ms

Open Reference Test - large Project: 753 ms

Code in Zip file is LV2009

Message Edited by Gleichman on 08-21-2009 06:36 PM

[Gleichman]

I converted the VIs and projects to LV8.5.1 with the following results.

Open Reference Test - No Project: 17 ms

Open Reference Test - small Project: 75 ms

Open Reference Test - large Project: 77 ms

So the execution was still slower in a project versus no project, but the size of the project did not effect execution. I've attached the LV8.5.1 code.

[NAKeel]

This was reported to R&D (# 183991) for further investigation. A possible workaround is to avoid using type defs in projects for the time being.  I will continue to investigate other possible workarounds.  Thanks for the feedback!

Nick Keel 

Applications Engineering 

National Instruments

[swenp]

Any news to this one?

We just tried to migrate a LabVIEW project with over 30k VIs to LabVIEW 2009f2 and stumbled into this huge problem. Using the project structure is no longer possible because it takes seconds of time to do some simple actions using VI references. This is definitely a blocker for us for using LabVIEW 2009.

I managed to track it down being a problem using typedefs and lot of VIs in the project just as Gleichman mentioned.

Not using typedefs is not a possible solution.

Any new hints?

[Neil.Pate]

---

A possible workaround is to avoid using type defs in projects for the time being.

---

YES! That is exactly the answer.

I mean, who uses typedefs anyway?

In other news, because of a bug discovered in LabVIEW, NI recommends as a workaround not to use sub-VIs, and suggest to exclusively use Express VIs instead. 

Doh!