jzoller Posted February 19, 2009 Report Share Posted February 19, 2009 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. Quote Link to comment
Rolf Kalbermatter Posted February 20, 2009 Report Share Posted February 20, 2009 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 Quote Link to comment
PaulG. Posted February 20, 2009 Report Share Posted February 20, 2009 I've taken part in numerous threads at NI's forum regarding references. Their seems to be the overwhelming consensus that with the exception of control references all references should be explicitly closed. Quote Link to comment
Yair Posted February 20, 2009 Report Share Posted February 20, 2009 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? Quote Link to comment
jzoller Posted February 21, 2009 Author Report Share Posted February 21, 2009 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. Quote Link to comment
Rolf Kalbermatter Posted February 22, 2009 Report Share Posted February 22, 2009 QUOTE (hari001 @ Feb 21 2009, 01:40 AM) Hi,Myself Jimmy from Canada. Thanks for the wonderful and useful information. I would like to know more about .net. 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 Quote Link to comment
Yair Posted February 22, 2009 Report Share Posted February 22, 2009 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. Quote Link to comment
Rolf Kalbermatter Posted February 23, 2009 Report Share Posted February 23, 2009 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.