What cause project to recompile & how to reduce it happening

[dannyt]

Please note this is a cross-post to the NI discussion forums (where I got no reply)

Hi All,

With all the recent talk about standards of postings I am now feeling a little nervous about posting on Lava . But after due consideration I feel this is a valid post and after all LAVA needs people to post stuff to have a reason to exist. I was surprised this raised no interest on the NI Boards, as I still do not think it a total stupid or irrelevant topic.

My interest in this question was re-awakened by a response to an of topic question (by me) in the thread My First LVOOP Project .

This was to do with my 'incorrect' expectation that by moving to a LVOOP Class based architecture, there would be a significant reduction in the number of VI recompiles by decoupling large amounts of the code.

I am interested in getting a better understanding of what type of changes to a VI, cause higher level VI's to recompile ? and what is the best approach to minimise this situation.

I understand the obvious changes, i.e adding / removing a front panel control or indicator, or the changing an indicator / control type and I can see how that will cause the calling VI to need to be recompiled. However sometimes I do changes that I would not expect to affect the calling VI but still it recompiles.

The particular thing I do not understand is the rules I should use to decide when to expect the ripple effect, whereby I change a sub-VI and not only does it's calling VI recompile but there is a ripple effect up the calling Hierarchy and often not for any reason that seems obvious or predicable to me.

Following on from the above, what can I do the forestall the ripple like compile situation, in particular

• Is it affected by the project directory structure and the stored locations of VI's releative to each other, for what I have do so far this appears to have no effect.
  

• I assume one of the best techniques to forestall this is to us a plug-in / dynamic loading of VI's type architecture.
  

• I had hoped that by moving to a LVOOP type architecture would reduce this but following a posting on the LAVA site I now believe that the effect would be the opposite. See link above.
  

cheers

Dannyt

Working in LabView 7.0 on Windows XP.

[crelf]

QUOTE(dannyt @ May 2 2007, 08:41 PM)

With all the recent talk about standards of postings I am now feeling a little nervous about posting on Lava

No need to be nervous dannyt - your post is nothing like the posts that were being shuned.

[Mellroth]

QUOTE(dannyt @ May 2 2007, 12:41 PM)

The particular thing I do not understand is the rules I should use to decide when to expect the ripple effect, whereby I change a sub-VI and not only does it's calling VI recompile but there is a ripple effect up the calling Hierarchy and often not for any reason that seems obvious or predicable to me.

Hi Dannyt,

I don't think anyone but NI could really answer this question, but I agree with you that recompilation is sometimes required for very strange reasons.

LV5.1 would never recompile (as far as I remember), due to changes in the block diagram, but only if changes were made to the connector pane somehow.

Since this version changes on the BD sometimes force a recompilation, e.g. adding a Case structure. I can only guess why we need to recompile due to an added case structure, but my guess is that the case structure is changing the way the compiler marks the wires connecting to the VI (e.g. if a copy is needed).

But again, I don't think anyone outside NI, can really answer this question completely, and I'm looking forward or at least hoping to see some NI response on this.

/J

[hooovahh]

QUOTE(dannyt @ May 2 2007, 06:41 AM)

With all the recent talk about standards of postings I am now feeling a little nervous about posting on Lava .

I know what you mean, at other forums I don't mind being funny, and kinda poking at people in a non threatning way (like making fun of crelf because he would know I'm kidding)

But here I feel nervous about every thing I post, (being fairly new here doesn't help either) but crelf assured me, just read the Guidelines http://wiki.lavag.org/index.php/Forum_Guidelines''>http://wiki.lavag.org/index.php/Forum_Guidelines' target="_blank">http://wiki.lavag.org/index.php/Forum_Guidelines and if you don't break any of the rules feel free to post. Of course there are quite a few rules, but there needs to be since we don't want this to turn into the NI forums. Not that it's NI's fault people abuse it. (is this off topic I don't want to break the rules)

[crelf]

QUOTE(hooovahh @ May 5 2007, 12:16 AM)

...just read the Guidelines and if you don't break any of the rules feel free to post.

That said, I don't think guidelines apply so strictly in the http://forums.lavag.org/LAVA-Lounge-f47.html' target="_blank">LAVA Lounge - nothing's sacred in there...

[Michael Aivaliotis]

QUOTE(hooovahh @ May 4 2007, 07:16 AM)

I know what you mean, at other forums I don't mind being funny, and kinda poking at people in a non threatning way (like making fun of crelf because he would know I'm kidding)

All of a sudden everyone's afraid to have a sense of humor? Sheesh. BTW, yes, this IS off topic and yes, it's allowed.

[crelf]

QUOTE(hooovahh @ May 5 2007, 12:16 AM)

(like making fun of crelf because he would know I'm kidding)

Bring it on

QUOTE(Michael_Aivaliotis @ May 5 2007, 02:28 AM)

All of a sudden everyone's afraid to have a sense of humor?

hooovahh's post (I think?) was partly an inside joke that perhaps should be explained a little more: he works with me and his comment might be more of a commentary on my office banter of the last few days more than anything else

[hooovahh]

QUOTE(crelf @ May 4 2007, 12:53 PM)

hooovahh's post (I think?) was partly an inside joke that perhaps should be explained a little more: he works with me and his comment might be more of a commentary on my office banter of the last few days more than anything else

Not necessarily, I am very cautious about posting here.

[crelf]

QUOTE(hooovahh @ May 5 2007, 03:09 AM)

Not necessarily, I am very cautious about posting here.

I sit corrected.

[Aristos Queue]

In the ni.com DevZone thread, I mentioned inplaceness. I didn't talk about LV classes since those have their own oddities, which are being ironed out. I'll mention it here since you explicitly asked about LVOOP...

In LV8.2, let's be blunt: My team got paranoid. When a VI is a member of a LabVIEW class, we'll recompile it six, seven times on a single mouse click. Oh, that's a bit of an exaggeration, but it's a measure of just how far we went on a couple of fronts. There were a number of cases that we couldn't prove we didn't need to recompile the VI, so rather than have a VI that needed to be recompiled not get recompiled, we went to the other extreme and made sure that just about everything recompiled all the time.

I believe that LV8.2.1 has flushed all the paranoia cases out. I think I can now say the following with confidence:

A VI will recompile:

* for a significant change of its own block diagram (you can change free labels for example without recompiling)

* for a change of a typedef used on FP or BD

* for a change of the connector pane of a subVI

* for a change of a subVI's inplaceness

* for a change of a subVI's scope (public/protected/private)

* for a change of name (File>>Save As) of any VI, library, or other item on which the VI depends

A VI in a LabVIEW class will recompile for the above reasons and these additional reasons:

* for a change of the class' private data control

* for a change of the class' inheritance [meaning the class changes who its parent is, not just an edit to the parent]

I *think* we are now at the point where you could build a source distrbution of a class and all its ancestors and hand it out to other developers and then build a source distribution of just one of the ancestor classes and give that out to those developers... assuming no connector panes changed and no public/protected/private scope changed, the descendant classes of the replaced parent should not need to recompile. The goal, which I *think* we have achieved, is to get to the point where a LV class could be distributed as a module, saved without block diagrams, and you could provide new versions of the parent class and even in a built app everything would keep working assuming the parent's public/protected API didn't change -- that includes an inplaceness change. Inplaceness has been largely invisible in LV heretofore, and we want it to stay that way for the vast majority of customers, but in some cases it's useful to be aware of. I can't go into any details here, but there are features under development in R&D to help the developer guarantee that the changes made to a class don't change the inplaceness of public/protected VIs, to help guarantee that no recompile of child classes will be necessary when a new parent version gets released. As always on those rare occassions when I alude to features still under development, no promises are made about what version, if any, such features will ever appear in.

[Michael Aivaliotis]

I think this is a good article for the LabVIEW Wiki. When does a VI get a recompile? LVOOP and non-LVOOP related.

[Mellroth]

QUOTE(Aristos Queue @ May 5 2007, 07:44 PM)

I believe that LV8.2.1 has flushed all the paranoia cases out. I think I can now say the following with confidence:

A VI will recompile:

* for a significant change of its own block diagram (you can change free labels for example without recompiling)

* for a change of a typedef used on FP or BD

* for a change of the connector pane of a subVI

* for a change of a subVI's inplaceness

* for a change of a subVI's scope (public/protected/private)

* for a change of name (File>>Save As) of any VI, library, or other item on which the VI depends

This is probably more or less covered in your first point, but I think it is worth a separate entry.

* a "conditional disable" structure in a VI will cause recompile, if the active selection symbol changes.

E.g. using the TARGET_TYPE symbol in a VI that is used in more than one target. Opening the VI (or building applications containing the VI), will then indicate changes of the VI if it was not saved for the specific target.

/J

[Aristos Queue]

QUOTE(JFM @ May 7 2007, 01:51 AM)

This is probably more or less covered in your first point, but I think it is worth a separate entry.

* a "conditional disable" structure in a VI will cause recompile, if the active selection symbol changes.

E.g. using the TARGET_TYPE symbol in a VI that is used in more than one target. Opening the VI (or building applications containing the VI), will then indicate changes of the VI if it was not saved for the specific target.

/J

Ok --- then we should add

"Loading the VI in a new version of LV"

"Loading the VI for the first time after it has been saved for previous"

"Loading the VI on a new platform (saved on Mac, load on PC)"

I was sort of treating all of those as changes to its own diagram, but I guess you're right that the diagram itself isn't really being edited under those conditions.

[Mellroth]

QUOTE(Aristos Queue @ May 7 2007, 05:58 PM)

Ok --- then we should add

"Loading the VI in a new version of LV"

"Loading the VI for the first time after it has been saved for previous"

"Loading the VI on a new platform (saved on Mac, load on PC)"

I was sort of treating all of those as changes to its own diagram, but I guess you're right that the diagram itself isn't really being edited under those conditions.

My expression was that the original list described why a open VI suddenly needed recompilation, then it made sense to add the conditional disable symbol only. You are right that if the goal is to describe any reason for a VI to need recompilation, these three new entires could be added.

/J

[Ton Plomp]

QUOTE(Aristos Queue @ May 7 2007, 05:58 PM)

"Loading the VI in a new version of LV"

I think it should say 'in a different version', because opening a 8.2.1 VI in 8.2.0 will also force a recompile

Ton

[Tomi Maila]

QUOTE(Aristos Queue @ May 5 2007, 08:44 PM)

A VI in a LabVIEW class will recompile for the above reasons and these additional reasons:

* for a change of the class' private data control

* for a change of the class' inheritance [meaning the class changes who its parent is, not just an edit to the parent]

In my experience it's quite normal that a LabVOOP project has unsaved changes immediately after it has been opened from the disk. Of course there really cannot be any chages but LabVIEW seems to think so and saves some VIs when one presses Save all.

Tomi

[Aristos Queue]

QUOTE(Tomi Maila @ May 8 2007, 08:14 AM)

In my experience it's quite normal that a LabVOOP project has unsaved changes immediately after it has been opened from the disk. Of course there really cannot be any chages but LabVIEW seems to think so and saves some VIs when one presses Save all.

8.2 or 8.2.1 ? To the best of my knowledge, all those are fixed in 8.2.1. If you know of a case that still has a problem, please file a bug report.