This article claims it’s pointless to Set objects to Nothing in VB when you’re finished with them, except in particular cases. Maybe it’s those particular cases I’ve come up against, but I don’t believe that, myself. I’ve observed time and time again IIS apps that call VB6 DLLs grabbing more and more memory for DLLHost, and eventually choking until an iisreset has been done.
Going through the code (both the ASP VB Script and the underlying DLL VB) with a fine tooth comb and ensuring EVERY object got set to Nothing afterwards cleared these issues. Though I’m embarassed to admit that on one early project I worked on, a bunch of people looked through the code trying to find the leak, couldn’t find it, and someone eventually wrote a nightly iisreset batch job.
Reading that article, it occurs to me that maybe there was a case of destroying objects that referred to each other in the wrong order. The code is long sinced vanished, so I don’t know, and don’t care to find out.
As far as I’m concerned, it’s not only better for performance to destroy your objects, and a helluva lot easier to do all the time than just some of the time. It’s also tidier in the code. I’ll keep on doing it.
.Net, of course, is a different kettle of fish altogether.