Why closing type definition uses so much memory and is so slow

[JÞB]

A library is one file, a project contains members. you seem to have a few poly-morphic vis too. 

So, explain to me what "std_" does for you?

And, just to make this interesting, Who still uses "_" and why?

what i'm stating, you have no project, you habe no libraries, you have no context! so, closing type-defs will take some time esspecially when they are strictly defined.  Still, I would be interested in YOUR view of why "std_" decorates your vi names?

[Sam_Sharp]

Create a support ticket with NI and post your example project and the full description you posted - it might take a while for them to get back to you (depending on service level), but they should be able to provide you with a proper answer. It would take less time than engaging in bickering and reading 'useless replies' in the forums 🙂

[natasftw]

---

@jacemdom wrote:

Please explain to me how does any of this relate to "Why closing type definition uses so much memory and is so slow"?

---

You've already been given likely explanations for this behavior.  Please explain to me how being harsh with anyone offering advice to help you get around this problem is of any use?  You whine about "useless replies" but ignore that bad programming practices are more at play here than the fact the typedefs are momentarily disabled and then need to be updated.  Your "simple test" isn't simple, by any definition.  It's a complex spiderweb of insanity.

The only answer you're willing to acept is from someone on the LabVIEW compiler team.  What was your purpose in posting here?  Wouldn't that be the very definition of useless?

[Dsun]

Seems like LabVIEW is scanning through all the VIs when you open up the Type Def control.  Since there is no way for LabVIEW to store all the uses of the Type Def control, it is likely pre-emptively searching through the VIs in case you change the control.  Since you have so many VIs loaded in memory this process is naturally going to take a while.

[billko]

---

@Dsun wrote:

Seems like LabVIEW is scanning through all the VIs when you open up the Type Def control.  Since there is no way for LabVIEW to store all the uses of the Type Def control, it is likely pre-emptively searching through the VIs in case you change the control.  Since you have so many VIs loaded in memory this process is naturally going to take a while.

---

That's a reasonable assumption.  That's probably how it can "Apply Changes" immediately.

[jacemdom]

---

Sam_Sharp wrote:

Create a support ticket with NI and post your example project

---

Done will post back results.

---

Dsun wrote:

it is likely pre-emptively searching through the VIs in case you change the control.  Since you have so many VIs loaded in memory this process is naturally going to take a while.

---

I also believe this and as you maybe already suspect, I am asking this question in the hopes of getting technical details about the actual changes that trigger this pre-emptive search.

I would also be interested to get information on why it does this on closing and not on opening or more transparently in the background once loaded?

What is sometimes problematic for me is that this occurs systematically and repeatedly even if there are absolutely no modifications done to anything. Just open top vi, open type def and then close type def. I don't mind waiting for LabVIEW to do its thing when there are modifications but waiting when there are no modifications whatsoever is something else and can become counterproductive. When I just open an enum type def to look at the list of items and then have to let it open because if I close it, tic...toc...tic...toc...tic..toc…and with some type defs it can even become tic...toc...tic...toc...tic..toc…BOOM! Memory goes through the roof and LabVIEW disappears without a sound! This happens at approximately 3.3GB on LV32 and 3.9GB on LV64. Looks like LV64 increased memory only applies to the data space and not the code itself.

As a possible workaround I also found out that closing the type def panel with VI server does not trigger the checking routine.

Please take the time to consider that this is a very pointy, precise issue and that my main intention is to increase my knowledge on this particular issue. Please don't ask me why I am interested in this or make assumptions that I should not need this in this discussion.

If you want to discuss unrelated or indirectly related issues on the subject or anything else, please use the private messaging system or create another thread.

Post-scriptum:

My personal thoughts related to the unrelated replies and some advice for those who made them.

If something affects 0.01% of users, it does not mean that it should not be investigated. It only means that 99.99% of users should not be or get involved.

A directed and biased question is no more a sign of openness and curiosity then professing the truth about one’s superior coding practices.

The efforts made to seem right and look good will ultimately lead to be wrong and look bad.

Not understanding the utility of something does not make it useless.

The number of posts in a forum is indicative of quantity, not quality.

My favorite:

Don’t try to save me from my own ignorance, I won’t understand!

[jacemdom2]

Here is the conclusion of the service request.

"From the DAbort lines in several crash dumps, it looks like these crashes are all caused by the same issue- the Image Table filling- and now that we are aware of it, it can be patched in a future update of LabVIEW. Thanks for bringing this to our attention!"

I belive this means that somewhere in the future they will fix the crash, but the high memory and cpu usage will probably remain and probably require much more effort to fix if ever fixed.

Reminder : If anyone encounters this situation, a simple way to avoid it is by closing the type def programmatically, this way the whatever routine is not triggered.