Slow LabView 2016 IDE

[EWiebe]

Hello all,

I have a big LabView Project (more than ~ 2000 VIs) loaded into LV2016 IDE.

(btw: when I create an executable it is ~38MB)

My problem is, that the LabView 2016 Environment (IDE) is very slow. In LabView 2014 (my previous version) it was not so slow.

I think it is not a problem of the Hard Disk because while the IDE is "no responding" the HDD led does not flash only the CPU is working.

I also noticed, that it uses only one processor core (my machine has 4).

Why it does not use all 4 cores? Perhaps this is the problem?

Is it possible to allow LabView to use all cores for the IDE?

What should I do?

I already tried to recompile all (CTRL+SHIFT+ARROW) but it did not help.

Here my system:

Dell i3-2120 (3.3GHz) with 4GB RAM (Windows 7 prof, SP1)

LabView 2016 (32 bit)

Thank you.

[Ben]

Could you pleas tell us more about your project and what features you are using aside from a lot of VI's.

The more information you can share the better.

Auto-populating floders?

Auto-save?

LVOOP?

In-lined VIs?

Where you doing anything at the time of the slowness?

Curious and trying to help,

Ben 

[EWiebe]

Auto-Populating: NO

Auto-Save: NO

LVOOP: Yes, many classes (see class diagram)

   Number of VIs in classes: 833

   size of all VIs and elements in classes: ~40MB

see attached video

It shows how long it needs to connect a simple wire

Perhaps it is a problem of my big VI (SUB Prüfung Sensor.vi) because when I create a new blank VI and insert the Class instances and some VIs there it seems to be very fast.

Is there a tool to analyze a VI and show problems (big memory consumption...) ?

Thanks.

EWiebe

[Ben]

Could you share your code with NI Support?

They can investigate further.

Edit:

I just watched and that absolutely sucks!

Please share that code with NI Support, PLEASE! 

Just trying to help!

Ben

[JÞB]

In addition to Ben's suggestions I would ask:

• Are you using Actor Framework?
• Is the Source separated from the VI Obj?
• Have you tried to clear the VI Cache?
• What SCC are you using?
• Are you using an integrated SCC framework? If so which and by whom?
• Is the help floater active? if so show the documentation properties of the vi's (Looking for help tags or odd help paths or web-based help files)
• Which Project view is active?
• What other floaters are active? 
• Looking at the ini options: AutoTool or tabbing? Automatic wiring or not?  List any non default-options (Hey, if you rename LabVIEW.ini then open LabVIEW does this still happen?)
• Are there Unit Tests in the project? Have they been run or modified prior to seeing this? (UTF leaves a bunch of stuff in limbo until LabVIEW is closed)
• What targets in the project?  What Context in the vi you are editing?
• What Environment? Is it the default environment? (Oh man that would be a bad thing if it wasn't)
• Disable Windows "Aero Themes" Does it still happen? (Side question: How many monitors and are you on the primary monitor when you see this?)
• Install f1 and f2 patches. Does it still happen?

I know, LOTS of questions.  Trust me, many people are very interested in exploring this behavior.  So please, help us help you help them help us.

[Ben]

Good additional Q's there Jeff.

While I have never personally experienced a slowdown like that, I do not want to ever see a slowdown like that!

My fixed price estimate would be a utter disaster!

So if we can figure out if there is something odd in your settings etc. I will at least know what NOT to do."

Ben

[EWiebe]

* Are you using Actor Framework? -> NO
* Is the Source separated from the VI Obj? -> NO
* Have you tried to clear the VI Cache? -> NO
* What SCC are you using? -> external: SubVersion
* Are you using an integrated SCC framework? If so which and by whom? -> NO
* Is the help floater active? if so show the documentation properties of the vi's (Looking for help tags or odd help paths or web-based help files) -> No other windows floating
* Which Project view is active? -> opened within a project and also as single file (after generating Source Destribution) didnt change behaviour: still needs very long time
* What other floaters are active? -> no other floaters
* Looking at the ini options: AutoTool or tabbing? Automatic wiring or not list and non default-options (Hey, if you rename LabVIEW.ini then open LabVIEW does this still happen?) -> if I rename Labvie.ini and start again still same behaviour
* Are there Unit Tests in the project? Have they been run or modified prior to seeing this? (UTF leaves a bunch of stuff in limbo until LabVIEW is closed) -> No unit tests in the project
* What targets in the project?  What Context in the vi you are editing? -> in project: exe targets, in single-file: no targets
* What Environment? Is it the default environment? (Oh man that would be a bad thing if it wasn't) -> default environment
* Disable Windows "Aero Themes" Does it still happen? (Side question: How many monitors and are you on the primary monitor when you see this?) -> disabling AERO didn't help. I use 2 monitors
* Install f1 and f2 patches. Does it still happen? -> Installed -> still same behaviour
    
    what I tried after that
    1. Recompile under LV2016 patch2 (CTRL+SHIFT+ARROW) then save then close LabView then restart LabView -> didn't help
    2. Disable AERO -> didn't help
    3. Separated source from vi obj for the "main" vi only then saved then restarted LabView then opened again -> didn't help
    4. cleared chache with compiled objects (User: 11MB, Appliaction Builder: 10MB) -> didnt't help
    
    so, nothing helped up to now 😞

[JÞB]

OUTSTANDING!

That's good stuff.

To clarify one point.  I take it you have only "MyComputer" as a target in the project( No RT or FPGA.)

So we need to dig a bit deeper (Trust me, this is good! a lot of bad things just became "Not-the problem")

Any Web-services or shared variables? (could you share a screen shot of the project explorer- both views please)

Any Conditional symbols?

With the project open and the vi shown before opened in project context. (Look at the lower left border there is a "Context" enum control that can switch the vi context.  We want that to show "<MyProjectName>.lvproj/MyComputer" or the localized equivalent since, that looks like a German instal.)   Run VIA on the vi  IMPORTANT USE The attached VIA Config file! upload the report.  EDIT: Expect some very strange errors I tweaked some test configurations to specifically show interesting metrics. 

Close the project and change Tools>Options>Environment> Compiler to 0  Relaunch LabVIEW Any change?  Even if it is still slow did it speed up noticeably?

[crossrulz]

Some of us just got out of a meeting with some NI R&D folks discussing slowdowns like you are showing.  One was due to excessive code complexity due to a lot of inlined VIs (and inlined VIs calling inlined VIs).  The other two we saw (one of which looks very close to what you are showing) were due to compiler and analysis inefficiencies NI found while analyzing those large projects.  I highly suggest you get a hold of NI support and get that code to R&D so they can use it to test with.  They may have the fix.  Now when those fixes get released is still to be determined.

[JÞB]

---

@crossrulz wrote:

Some of us just got out of a meeting with some NI R&D folks discussing slowdowns like you are showing.  One was due to excessive code complexity due to a lot of inlined VIs (and inlined VIs calling inlined VIs).  The other two we saw (one of which looks very close to what you are showing) were due to compiler and analysis inefficiencies NI found while analyzing those large projects.  I highly suggest you get a hold of NI support and get that code to R&D so they can use it to test with.  They may have the fix.  Now when those fixes get released is still to be determined.

---

And some of us didn't get an invite.   I just went through some notes from the meeting.  Now i'm very curious as to the results of the VIA on that vi with the special config I attached.  It is tweaked for massive cyclic complexity failures and inlinability / paralizability