Fastest way to destroy a tree structure in VB6

Question

I have some code in VB6 which creates a moderately-large tree structure (a few thousand nodes). Performance is adequate except when destroying the last reference to a tree. That can sometimes take a second or more. I've tried killing all the internal references within each node before deleting the node itself, but that doesn't seem to help. Is there some trick to speed up whatever vb6 is doing with its reference counters? There seems to be a significant N^2 aspect to the performance.

Incidentally, I know VB6 is obsolescent, but I have someone complaining about this code which I wrote quite some time ago but which is still in use.

BTW, the tree is not a binary tree, but instead allows each node to have an arbitrary number of children, held in a Collection and accessed by name (so one node might be TheTree!This!That!TheOtherThing!Whatever, aka TheTree("This")("That")("TheOtherThing")("Whatever")).

Answer 1

VB6 collection objects are notorious for being slow to release their contents, esp when there's a lot of contained references.

You might try a replacement collection, like this. There's a number of other replacement Collections for VB6 that should be essentially drop in compatible.

You might also want to read up on Bruce Mckinney's take on the collection object.

EDIT: More Bruce McKinney info here

Answer 2

I hate to be the bearer of bad news, but I doubt you'll be able to reduce the amount of time that it takes to terminate the object tree. 10 years ago or so I co-developed SQL Accord in VB6 -- an application that did database comparisons. So as you can imagine you are holding thousands of objects in memory (e.g. table/view/sproc/etc definitions) to be able to quickly compare them.

The initial design of holding these objects in collections fell on the floor due to the issues that the OP brought up. The culprit is the COM garbage collection scheme - it needs to clean up the moment you set the object to Nothing/Null and then most likely it needs to defrag the memory space - that takes time.

My solution (painful at the time) was to convert all objects into TYPE structures and convert collections into arrays of types. Then I built manager objects to deal with the arrays/types/etc...

Even though the code smells when you look at it - I got a 10x performance increase out of it. Why? Because TYPE structures go on the stack, while objects go on the heap, where it is much more expensive to dispose of them.

Answer 3

Curland's Advanced Visual Basic explains how to create lightweight COM objects and how to organize instances of these in large systems of objects that use custom memory manager. The benefit is basicly that you can allocate a large single (or several but not many) chunk of memory to store all the instances that can be released in one go. This reduces tear down time to zero.

Lightweight objects are structs (Types in VB6) wrapped in COM interfaces so to look like regular COM objects. Arrays of UDTs are allocated and destroyed very fast as these occupy a single chunk of memory.