Jump to content

Cleaning up .NET refs


Recommended Posts

When a .NET refnum is used within LV to reference other .NET refnums, do these sub-refnums need to be explicitly closed?

My little experiments seem to indicate that the sub-refnums do not need to be explicitly closed, but any advice would be appreciated.

See the attachment for an example.

Thanks,

Joe Z.

Link to comment

QUOTE (jzoller @ Feb 18 2009, 04:35 PM)

When a .NET refnum is used within LV to reference other .NET refnums, do these sub-refnums need to be explicitly closed?

My little experiments seem to indicate that the sub-refnums do not need to be explicitly closed, but any advice would be appreciated.

See the attachment for an example.

Not sure about .Net references but if it is anything like ActiveX then yes they would need to be closed explicitly if you do not want them to linger around in memory until you stop or close the Top Level VI in whose hierarchy the reference was created.

This last one is a LabVIEw specific feature since it keeps track of all its refnums and destroys them when the Top Level VI in whose hierarchy the reference was created goes idle. When it destroys its refnum it also closes the underlying ActiveX or in this case .Net handle. Otherwise the ActiveX handles would remain in memory until the process that created them is going to terminate in which case Windows process cleanup code takes care about closing anything still left open.

Rolf Kalbermatter

Link to comment

This may have changed recently, but at least in the past, NI's "official" recommendation was to close ALL .NET references. See this post by Brian Tyler, who used to head LV's .NET team.

This might have changed, however. Since the references have a clear scope, I can actually imagine NI releasing them automatically. Can you provide details regarding the tests you ran?

Link to comment

QUOTE (Yair @ Feb 19 2009, 11:00 AM)

This may have changed recently, but at least in the past, NI's "official" recommendation was to close ALL .NET references. See http://detritus.blogs.com/lycangeek/2006/05/how_to_say_good.html' rel='nofollow' target="_blank">this post by Brian Tyler, who used to head LV's .NET team.

This might have changed, however. Since the references have a clear scope, I can actually imagine NI releasing them automatically. Can you provide details regarding the tests you ran?

Thanks Yair, Brian's post seems pretty adamant about closing everything. I'm guessing that .NET doesn't report the underlying ref going out of scope back to LV... a few more experiments seem in order.

My tests were very simple: create a lot of sub-refs, then attempt to orphan them by closing the top level without closing the sub-refs. Repeat a few thousand times. Monitoring memory while this happens doesn't show any particular increase.

Link to comment

QUOTE (hari001 @ Feb 21 2009, 01:40 AM)

http://msdn.microsoft.com' rel='nofollow' target="_blank">MSDN is your friend for detailed information about specific .Net functionality. For learning how to program it I would recommend you to get a good book about it from publishers like McGrawHill, Prentice-Hall or similar.

Rolf Kalbermatter

Link to comment

That post is spam and has been reported as such.

QUOTE (jzoller @ Feb 20 2009, 08:19 PM)

My tests were very simple: create a lot of sub-refs, then attempt to orphan them by closing the top level without closing the sub-refs. Repeat a few thousand times. Monitoring memory while this happens doesn't show any particular increase.

The increase should happen as soon as you open the refs. You should first do a test (with many millions of refs) where you open the refs and wait and then check the memory usage. I suppose there is a possiblity that you won't see the memory increase at all (e.g. if .NET is doing everything out of process), but I don't think it works that way. That said, I know pretty much nothing about .NET, so I'm not exactly an authority.

Link to comment

QUOTE (jzoller @ Feb 20 2009, 02:19 PM)

Thanks Yair, Brian's post seems pretty adamant about closing everything. I'm guessing that .NET doesn't report the underlying ref going out of scope back to LV... a few more experiments seem in order.

Yes I don't think there is any way .Net could call back into LabVIEW to let it know that it has autodisposed a refnum. But then they might want to do that for their Visual Basic environment so maybe, but I doubt it would be officially documented.

QUOTE

My tests were very simple: create a lot of sub-refs, then attempt to orphan them by closing the top level without closing the sub-refs. Repeat a few thousand times. Monitoring memory while this happens doesn't show any particular increase.

Unless .Net can call back to LabVIEW to let it know about the the disposal of the objects there would need to be some memory allocation for the LabVIEW .Net refnum, as long as the returned object is not static. So maybe you tried with something that is static, meaning it always returns the same object and does not instantiate them. I believe LabVIEW knows about if an .Net object is static and might handle it differently than normally instantiated objects.

Rolf Kalbermatter

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.