Re: Tips on finding memory leaks

Yeah, I'm aware of the failings of the Collection object in VB, but for what
I'm doing, I think it's good enough, since I don't think I have a single
collection of anything that's more than a few hundred items. And I prefer
using an Object Model rather than a database for the ability to implement
checks, have higher-end code running, etc. In this case, it's both the
business-rules tier and data tier combined, so is very useful to have as an
object rather than a recordset.

The problem I think, which you touched on, is the number of collections of
objects which are collections of objects which are...and they told two
friends, and so on and so on and so on...(old shampoo commercial from the
early 80's, I think, in case you didn't get the reference).

Speed is certainly an issue here as well, but I believe that can be
rectified fairly easily with caching a few commonly-accessed read-only
tables client-side. But when Access reports that it's using 500M of memory,
when it was using less than 100M before I started generating a bunch of
reports, I tend to be suspicious that there's something not-quite-right with
my VB DLL, which was really the only thing being accessed in any meaningful
way during report creation. :-)

The problem is that at least with Access as the front-end, and ADO in the
mix, I can't always expect that memory used will be the same before and
after I create an object. I'll have to give it a shot taking Access out of
the mix temporarily (that's WHY I have a data tier, after all!) and see if
that leads to any new insights.

Does anybody know a way of telling ADO to flush every damned thing it can
and revert to a minimal-memory profile? I think if could do that before &
after any tests, it would help pinpoint problems significantly.


Rob

"Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
news:ejBltEnQIHA.5288@xxxxxxxxxxxxxxxxxxxxxxx

"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




.