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

[jacemdom]

---

@Sam_Sharp wrote:

You can have package dependencies (e.g. for your basic libraries/building blocks) - we moved away from having a big monolithoic reuse folder to VI packages and we'd never look back.

---

If i understand correctly, there would still be some VIs used in all packages. If that is the case, then i would end up with the same problem of loading all the packages in memory to avoid broken code when modifying a shared type def.

[Sam_Sharp]

No, because you would only update the other packages when you need to and they wouldn't be loaded into memory. For example, I have a message queue library which is used in most of the shared libraries - if I want to update it, I update the source for that package, build the package and then install it. The other packages that use it, don't necessarily need to be updated straight away - only when they get loaded into memory by my project and it may be that they just need to be recompiled (e.g. if you add a case to a typedef).

The main difference is that the packages only get loaded into memory when they are used/needed.

VI Packages also create the appropriate folders/locations etc. in the palettes - this means you don't need a 'vi tree' to find everything 🙂

[billko]

---

@Sam_Sharp wrote:

No, because you would only update the other packages when you need to and they wouldn't be loaded into memory. For example, I have a message queue library which is used in most of the shared libraries - if I want to update it, I update the source for that package, build the package and then install it. The other packages that use it, don't necessarily need to be updated straight away - only when they get loaded into memory by my project and it may be that they just need to be recompiled (e.g. if you add a case to a typedef).

The main difference is that the packages only get loaded into memory when they are used/needed.

VI Packages also create the appropriate folders/locations etc. in the palettes - this means you don't need a 'vi tree' to find everything 🙂

---

I've read that "VI tree" VI is actually used to document how the VIs and subVIs relate to each other, and not just to "find" everything.  (Source: Developing LabVIEW Plug and Play Instrument Drivers.)

[JÞB]

I'll jump right in,  (sometimes I dislike that magic ball)

Close LabVIEW, unload the Viewpoint Systems TSVN TK! then reboot 

Next, find smaller reuse groups!  *.lvproj are very nice.  There is a balancing act with lvlibs and other dependancies like, even dll's.  My clue to chime in was "the cpu usage goes to 100% and the memory jumps to 2309MB"  2G in memory!  Fine for a 64bit app.  Not so good for TKs designed for normal users.  It sounds like you are not in the 95% of users that use that tool.

Spoiler

For whatever its worth, I know what installing serial #1 feels like in the field-  Being on the "B"leeding edge can hurt.

Now, I'll go on to state-  "Tree.vi" is obsolete!  It packs a ton of "Broken - because the required input is not wired" errors or, needs huge and unnecessary chunks of data! Just, "Go to Nirvana" and publish the APIs for the core Action Engines (classes) and put them in User.lib

[jacemdom]

I believe the question asked is quite clear and also believe that making assumptions on why i am asking this question will not bring me the answer i am looking for. If you really want to help me, download the example and try to explain to me why there is a 20MB ram increase on type def closing. What creates the 20MB increase in this 21 file example is probably the same thing that creates a significantly larger increase in significantly bigger hierarchies.
 

I am also not looking for hypotheses but for actual information on what is going on under the hood and therefore highly doubt that anyone who has never worked for NI or is not working with NI close to the compiler will be able to give accurate information on the subject.

As for the why, I am currently developing and testing advanced development and refactoring tools for LabVIEW and this creates needs that are probably not those of 95% of users but that will probably benefit 99% of them.

If i ask for a straw, don't offer me a bib or question my need for a straw stating that a sippy cup would be better. Don't get me wrong, bibs and sippy cups are very useful but i want to use the straw to vacuum a sandwich bag!

[Sam_Sharp]

Maybe then you should contact NI Support? This is a community forum and so the answers here generally from members of the community - it's generally pretty unlikely for someone from NI to respond, and much less likely someone from LabVIEW R&D. I think you're being a little harsh as we're just trying to help / offer some insight to possible causes and solutions/workarounds.

If you get a response or CAR, then post it here so others can find it.

[JÞB]

---

@jacemdom wrote:

I believe the question asked is quite clear and also believe that making assumptions on why i am asking this question will not bring me the answer i am looking for. If you really want to help me, download the example and try to explain to me why there is a 20MB ram increase on type def closing. What creates the 20MB increase in this 21 file example is probably the same thing that creates a significantly larger increase in significantly bigger hierarchies.
 

I am also not looking for hypotheses but for actual information on what is going on under the hood and therefore highly doubt that anyone who has never worked for NI or is not working with NI close to the compiler will be able to give accurate information on the subject.

As for the why, I am currently developing and testing advanced development and refactoring tools for LabVIEW and this creates needs that are probably not those of 95% of users but that will probably benefit 99% of them.

If i ask for a straw, don't offer me a bib or question my need for a straw stating that a sippy cup would be better. Don't get me wrong, bibs and sippy cups are very useful but i want to use the straw to vacuum a sandwich bag!

---

OK, ( And i'll be as clear as possioble)

You have an std_! 

and a fvi_ and a lib_ problem.  ntd_  and pvi_ too!

So [Edit that actaul comma for a "Comma, pause for effect"] why are you using "_"?  Yup, and when you understand what FQN means we can have a better conversation.

Spoiler

Yes, i'm a bit "pissy" this morning.  "Fully Qualified Name"  No "_" required! 

[jacemdom]

---

@Sam_Sharp wrote:

Maybe then you should contact NI Support? This is a community forum and so the answers here generally from members of the community - it's generally pretty unlikely for someone from NI to respond, and much less likely someone from LabVIEW R&D. I think you're being a little harsh as we're just trying to help / offer some insight to possible causes and solutions/workarounds.

If you get a response or CAR, then post it here so others can find it.

---

This issue is not a deal breaker for me. Did not intend to be harsh, but to be incisively clear on the issue. I had no high hopes of getting an in depth answer to my question but did not expect to get this quantity of useless replies. It is clear to me and i am thankfull that some really tried to help to their best, workaround or not, but it is also clear that some did not even make the effort to or could not understand the problem at hand, or maybe even worst, that had to answer for the sake of answering.

I am far from the point to invest the time needed to contact NI support on the issue has i am pretty sure that i won't be able to workaround the issue. This becomes an issue only when i am going through massive refactoring efforts and this does'nt happen so often. The question is really more out of curiosity and learning then about fixing something, altough i would love to fix or avoid it.

---

@JÞB wrote:

OK, ( And i'll be as clear as possioble)

You have an std_! and a fvi_ and a lib_ problem.  ntd_  and pvi_ too!

So [Edit that actaul comma for a "Comma, pause for effect"] why are you using "_"?  Yup, and when you understand what FQN means we can have a better conversation.

Spoiler

Yes, i'm a bit "pissy" this morning.  "Fully Qualified Name"  No "_" required! 

---

If you want to have a discussion on naming conventions or your mood, please create your own posts. The question here is "Why closing type definition uses so much memory and is so slow". If you focus on the naming convention you are missing the point and wasting the time of the people interested in the answer to "Why closing type definition uses so much memory and is so slow".

Unless you are suggesting that the naming convention is the cause. Are you?

[JÞB]

---

@jacemdom wrote:

---

@Sam_Sharp wrote:

Maybe then you should contact NI Support? This is a community forum and so the answers here generally from members of the community - it's generally pretty unlikely for someone from NI to respond, and much less likely someone from LabVIEW R&D. I think you're being a little harsh as we're just trying to help / offer some insight to possible causes and solutions/workarounds.

If you get a response or CAR, then post it here so others can find it.

---

This issue is not a deal breaker for me. Did not intend to be harsh, but to be incisively clear on the issue. I had no high hopes of getting an in depth answer to my question but did not expect to get this quantity of useless replies. It is clear to me and i am thankfull that some really tried to help to their best, workaround or not, but it is also clear that some did not even make the effort to or could not understand the problem at hand, or maybe even worst, that had to answer for the sake of answering.

I am far from the point to invest the time needed to contact NI support on the issue has i am pretty sure that i won't be able to workaround the issue. This becomes an issue only when i am going through massive refactoring efforts and this does'nt happen so often. The question is really more out of curiosity and learning then about fixing something, altough i would love to fix or avoid it.

---

@JÞB wrote:

OK, ( And i'll be as clear as possioble)

You have an std_! and a fvi_ and a lib_ problem.  ntd_  and pvi_ too!

So [Edit that actaul comma for a "Comma, pause for effect"] why are you using "_"?  Yup, and when you understand what FQN means we can have a better conversation.

Spoiler

Yes, i'm a bit "pissy" this morning.  "Fully Qualified Name"  No "_" required! 

---

If you want to have a discussion on naming conventions or your mood, please create your own posts. The question here is "Why closing type definition uses so much memory and is so slow". If you focus on the naming convention you are missing the point and wasting the time of the people interested in the answer to "Why closing type definition uses so much memory and is so slow".

Unless you are suggesting that the naming convention is the cause. Are you?

---

First, I'm in a better mood- please, accept my appology.

The naming convention does not appear to be the cause!  Rather, the naming convention is a sign that you are unneccessarily over complicating your code structures!

For instance: after unzipping your attachment (and, to PROVE I'm in a better mood...how many forums would leave that phrase uncensored?) I noticed only *.vi and *.ctl extensions.  Where are the *.lvlib or *.lvproj files?  Yes, you need libraries for your reuse code and projects for deployable solutions.  4-5k files per project should also be reconsidered.

So, I'll ask, at the risk of offending you again, why do you decorate the file names when you SHOULD read the whole FQNs and put the components away in the libraries and projects they should be in?

I understand that packing components into source files is a tough balancing act!  You need to understand the user case! Often that means projecting how your developers will use those "Tools_" to delight clients.  You seem only a few degrees off! You have an "std_lib_" that should probably be converted to "Std.lvlib" We could talk some more.......

[jacemdom]

---

@JÞB wrote:

First, I'm in a better mood- please, accept my appology.

The naming convention does not appear to be the cause!  Rather, the naming convention is a sign that you are unneccessarily over complicating your code structures!

For instance: after unzipping your attachment (and, to PROVE I'm in a better mood...how many forums would leave that phrase uncensored?) I noticed only *.vi and *.ctl extensions.  Where are the *.lvlib or *.lvproj files?  Yes, you need libraries for your reuse code and projects for deployable solutions.  4-5k files per project should also be reconsidered.

So, I'll ask, at the risk of offending you again, why do you decorate the file names when you SHOULD read the whole FQNs and put the components away in the libraries and projects they should be in?

I understand that packing components into source files is a tough balancing act!  You need to understand the user case! Often that means projecting how your developers will use those "Tools_" to delight clients.  You seem only a few degrees off! You have an "std_lib_" that should probably be converted to "Std.lvlib" We could talk some more.......

---

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