problem: shutdown time proportional to runtime

[Neil.Pate]

Hello Experts,

I am developing a fairly large application using multiple queued state-machines as the fundamental architecture.

I have noticed that the shutdown time of the application, i.e. in the IDE after the final VI terminates there is a noticeable delay before the VI returns to edit mode.

The odd thing is that it is proportional to the length of time the main VI has been running.

My first thoughts were an unbounded array growing (and then being released) but the memory usage of the application is rock solid.

Then I thought, it could be a reference opened somewhere and not closed, but I am not really doing this at all in my application. I am using control references a lot, but you dont need to manually close these do you?

I cannot think of anything else which would be "building up" inside the application as it runs. All the queues are sensible sizes, and the final VI actually closes in good time, its the delay after this that is troubling me...

I do not have any custom DLLs in the application, and only one activeX control (which I am going to try and disable now to see if this helps)

Any ideas?

[Robert_Lee_NIUK]

Hi NRP, very strange behaviour indeed!

When you run the execution highlighter, what happens when you reach the end of your top level VI? Can you see it pasuing at any subVI's etc? I'm sure you must have done this etc, but just wanted to check. This only happens with this particular VI yes? which indicates that somethings not being released etc somewhere... Have you tried it on another dev PC. What ahappens if you run it as an exe (if this is possible?).

Sorry for a thousand questions,

[Neil.Pate]

Hi Rob, thanks for your suggestions.

I eventually sussed it though, in a place I would not have expected...

I coded a routine to defer front panel updates when doing lots of graphical changes. The VI takes a control reference as an input (any control on the front panel to be deferred) and from this it determines the owning VI and from this it can get a reference to the panel. It seems that these references never get closed, and as I was calling this function many times it was creating new (and different) references to the panel each time. The memory usage increased ever so slightly over time (I had not noticed this before).

When the app finally closed I suppose all these references got cleaned up, and this was what was taking a proportional length of time.

The solution was to use a more sophisticated routine (not terribly clever though) that only derives the reference once, and then stores it in a feedback node for each other time the VI is called.