Re: Tips on finding memory leaks

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Robert Morley" <rmorley@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:u5QFktcQIHA.1208@xxxxxxxxxxxxxxxxxxxxxxx
Does anybody have any tips on finding memory leaks in VB code,
particularly
in conjunction with ADO? I've got a data tier which seems to be more than
a
bit leaky, and I'm not entirely sure where the problem lies. It's
particularly hard to pinpoint, given that I know ADO caches data and so
forth, so I'm never entirely sure when to expect all my memory to be
returned and when not.

I know the obvious one of de-referencing objects, and I'll certainly look
for those, but beyond that, I'm not sure what else to look for. I suspect
some of the reference problems may be hidden in collection classes that're
allocating space of child objects, but not properly de-allocating them,
even
when the parent class itself is shut down, but I'm not sure how to go
about
proving that or rectifying it.

Any suggestions, either specific to ADO, collections, or just general to
VB,
would be appreciated.


Here is one article:
http://support.microsoft.com/default.aspx?scid=kb;en-us;248014

[Ghod, I miss Soft-ICE. <g>]

As for tracing memory leaks with VB, I have no good advice. If you were
using VC++ then you have a few more tools to both peek and play. The main
trouble with VB is it doesn't matter where the problem is occurring as you
will likely need to re-architect your code to get rid of it. That is, it is
seldom a spot-fix. As VB is too far removed from the source. (The universal
problem with a RAD tool.)

The other issue is simply the number of actors in any one scenario. First
there is your code, then ADO, then the connection Pool, then the Provider,
then the database engine.

As for your code - you mentioned "collection classes". VB's Collection is
not the best performing creature around. Anytime you are abusing them to any
extent I suggest you look around for one the many substitutes available on
the web.

As far as releasing memory goes, VB Collection objects while darn slow, are
very deterministic, i.e.. the memory will get released. So I wouldn't waste
time over that - with the single exception of Collections that contain
objects that contains references to other objects. You obviously have to be
very careful that everyone cleans up after themselves. If you have done
that, then the Collection will do its job.

For critical situations I have found that just about the only way to narrow
it down is to create various simplified Test Beds, and test, change, test,
change, test, .. <g>

Something else I will throw out to you even though I know you well enough to
believe you are already aware of this. I only bring it up because you
mentioned collections and child objects along with ADO. Often when designing
an OO front-end for a relational database, we need to mine the data and then
build an object model - which always leads us into impedance-mismatch
problems.

For example, reading in a bunch of recordsets and using them to construct a
Object Model that is a collection of child objects, when that is exactly
what a Recordset is: "A collection of collections contains objects". Often
it is simplier to rework the query (or even the data store) to retrieve a
Recordset which can then be wrapped with an object to provide the same
information and ease of access that building an object Collection can - and
usually at far less expense. e.g., let it factory-build child objects on
demand, and destroy when no longer needed.

The other reason I mention it is because usually when we run into "memory
problems" - it isn't memory that is the problem - its because we have made
too many demands on it and have reached the edge of the envelope and
probably should look at another way to get the same results. Not every ideal
object model scales well. <g>

hth
-ralph


.

Relevant Pages

  • Re: Any REAL reason to use ADO vs. DAO?
    ... I've run this test and I've _NEVER_ seen DAO faster than ADO ... has little to do with marshalling a recordset object across processes. ... Here both, ADO and DAO, don't allocate much Memory (no Copy ...
    (microsoft.public.vb.general.discussion)
  • Re: running out of memory
    ... First of all it is not ADO, ... using of the SQL statements on a server side inside of SP to do this rather ... > I've found that looping through an ado recordset will cause memory ... > if it's a large recordset. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Tips on finding memory leaks
    ... But when Access reports that it's using 500M of memory, ... The problem is that at least with Access as the front-end, and ADO in the ... mentioned collections and child objects along with ADO. ... what a Recordset is: "A collection of collections contains objects". ...
    (microsoft.public.vb.general.discussion)
  • Re: Recordset.AddNew and the recordset objects data retaining
    ... via an ADO recordset, then I'd strongly suggest you redesign your solution. ... > to do with the updates being in a transaction but rather on whether you specify ... > spill over and the memory starts paging out to disk that concerns me). ...
    (microsoft.public.data.ado)
  • Re: filter with vb code
    ... I guess ADO classic doesn't interest them. ... There may be no recordset in your post be there certainly is a memory ... SQL involving an open workbook causes a memory leak. ...
    (microsoft.public.excel.programming)