Slow LabView 2016 IDE

[Ben]

please forgive me if I fell behind and missed it above.

Have you tried the ini ...

LiveDrag=false

and shutting off Auto-explode errrr... "Auto Grow" ?

Ben

[EWiebe]

LiveDrag=false  --> didn't help

But I have on other idea: save for LV2014 and import in LV2016 again...

I will try and inform...

[Yamaeda]

That reminds on an issue of mine in a 2014 project, but yours is worse. Try running without the project and use Classes directly, and if you must use the project, change to File mode, and see how that works.

If you could send it to NI and they could pin it down it'd help me also (i couldn't send my code)

I suspect it gets stuck in some dirty bit update loop where the change in the VI trigger the projects that dirties the other classes, which dirties the project and so on.

/Y

[EWiebe]

1. saved for LV2014 and opened in LV2014 -> normal fast operations

2. opened the same code in LV2016 -> SLOW (needs ~1..2 minute for simple wire connection)

😞

BTW: Has anybody from the R&D department looked at my code published in the service request #7704947?

Thank you in advance

BR

[Ben]

---

@EWiebe wrote:

1. saved for LV2014 and opened in LV2014 -> normal fast operations

2. opened the same code in LV2016 -> SLOW (needs ~1..2 minute for simple wire connection)

😞

BTW: Has anybody from the R&D department looked at my code published in the service request #7704947?

Thank you in advance

BR

---

Last question two from me ...

If you just open the VI and NOT the project, how is the edit time?

Was NI Support able to duplicate the slow edits using your code base?

I sent a message to my contact in R&D.

I have not heard back from them as of this time.

To set your expectations...

A problem like this one may not be fixed fast depending on what they find. Just trouble shooting a problem like this make take some time. Since the issue you are seeing has not been fixed by any of our guesses, and it has not been reported previously... they are going to have to dig into dark places to figure what is unique about you project.

But looking down the road...

Once they ID an issue they roll the changes into the shipping product in a controlled manner. It should "get better" but not even the developers can predict "WHEN?". 

They will do their best is the one thing that I can write with certainty.

Ben

[EWiebe]

If I just open the VI and NOT the project, the edit time the same.

It just takes so long, I guess the same amount of time.

[Ben]

Thank you Eugen!

I now have to bow out and let the machine take over.

"...and grant me the wisdom to know the difference."

Ben

[EWiebe]

I found the possibility to debug the LabView IDE:

adding "debugging=True" and/or "memorychecking=True" to LabView.ini

But it doesn't show sth. spectacular while the long operation (for me).

Perhaps it will help the R&D team...

see attached files.

dbg: debugging=True

dbg+mem: debugging=True  and  memorychecking=True

file "dbg_Open... .LOG"   :

Line            My Operation

0.. 671        Open LabView and Project

730..1052   Open VI (SUB Prüfung Sensor.vi)

1058..1077  my long duration connect wire operation

then i closed LabView and added "memorychecking=True" to LabView.ini

the results are shown in "dbg+mem...LOG"

my operation was around line 536..653

Thank you for support

[RavensFan]

Really cool logs.

Both line 730 and 536 in the other log had a "ran out of menus -- growing table" right before a large difference in time to the next log.

The other interesting thing  there were some "Inferring owner" items that seem to have long deltaT's right before or right after them.  That sounds like a library search problem.  It even lists some subVI's by name.  Check them out and see if you can find anything unusual about them or there library ownership.

You might even be able to analyze the logs yourself in LabVIEW.  Load the files into arrays and do a difference in time between each step.  Then map them out on a graph and look for the large deltaT's.  Find those lines and read the description.  (though it sounds like the ones listed above are probably the major points.)

[ChrisStrykesAgain]

I haven't really had time to dig in yet, but can you try opening your project in 2015? Does it have 2014 levels of performance, 2016 levels, or somewhere in between? There are several things that could be going on and that will help us narrow in.