Question about opening a vi reference in a sub-vi in a loop

[billings11]

I have a weird question that has to do with a performance change I saw between Labview 7.1 and 8.2.  Maybe someone knows something about this.

Basically when I upgraded to 8.2 I found a couple of memory leaks in my code.  They didn't really cause memory to increase actually, but they caused labview to take several minutes to close if I hit the abort button.  I tracked it down to a couple of spots where I was inadvertently calling a vi reference in a sub-vi in a loop.

So if I run this in either 7.1 or 8.2, I can call hundreds of thousands of instances of the vi ref in a loop.

But if I take the above code and sub-vi it like this:

Now if I run this for a couple seconds labview takes a long time to close, and if I run this for several minutes labview will basically hang entirely when I abort the vi.

But if I do the same thing in Labview 7.1 the performance is exactly teh same regardless of whether the open vi reference is in a sub-vi or not.

So what changed?  I don't really care about the difference, as I probably shouldn't be doing this in a loop anyway, but what is different in 8.2 that caused the change?

[falkpl]

Small sidenode in LV 8.2 you have a "this vi" reference in the application pallett so y7ou dont need any code to get a self ref to a vi.

Paul

[altenbach]

Opening millions of new references without ever closing any has always been something that should be avoided at all costs.

Sorry, I don't know if anything has changed between versions.

[billings11]

Of course, but I am interested in knowing what changed, just for my own edification. 

Obviously something changed between the two versions.  And what is strange is that there is no problem at all opening millions of vi references as long as I am not passing the reference control out of a sub-vi terminal.

There is an openG function that did this exact function, and I was actually using it in one of the states in a state machine.  So the state machine would continually go through a repeating cycle, and after several days I would start to notice labview would take forever to close if I stopped the vi.  So its not like I did something as noticably dumb as the example I showed, but it is interesting to me what is actually occuring inside labview here, and why it didn't have a problem in 7.1.  I find the more i know about the innards of labview's memory allocation and management, the easier it is to good-performing code.

[billings11]

falkpl,

I'm not seeing it.  Are you sure its in application control?

I'm interested in trying it to see if it is actualy opening a new reference every time you use it.

Message Edited by billings11 on 09-27-2007 12:48 PM

[billings11]

You mean to use the static vi reference and link it to the vi?  I tried that and interestingly it is not actually opening a new application reference each time.  Its just giving access to the same reference over and over again I guess.

[falkpl]

Yes I was refering to the vi ref.  When you select it it comes up as "this vi".  Just a little easier then opening a reference to the current vi's location.

Paul 

[billings11]

When I select it and drop it on a diagram it comes up with a question mark and the run arrow is broken until I select a vi by file path.  I don't see any option for "this vi".

[falkpl]

Sorry I should be more exact, I meant the vi server ref not static vi ref.  Is this the ref you used?  It should link by default to "this vi".

Paul

[billings11]

I see its the VI Server reference.

Message Edited by billings11 on 09-28-2007 02:58 PM