Performance and Freeing Very Many MSVB6 Objects 
Author Message
 Performance and Freeing Very Many MSVB6 Objects

I am working with a complex legacy DLL written in Microsoft Visual
Basic 6.  This DLL is called by programs outside my control.  The
DLL's method takes objects as input parameters, creates very large
quantities of temporary objects, processes the objects, sets the
temporary objects to Nothing, and returns other objects as output
parameters.  There can be hundreds of thousands of objects to free.

Execution time is dominated by the freeing of the temporary objects
created inside the method.  I cannot wait until the program exits to
free the temporary objects because they take so much memory.

Does anyone have suggestions on how the DLL's method can avoid waiting
on the freeing of the objects?

I have been wondering about processing the temporary objects in
another thread.  Ideally, the current method would pass the input
parameter objects to a new method in a new thread.  This new method
would create and process the temporary objects.  The new method would
pass the output parameter objects to the original thread before
freeing the temporary objects.  However, I am not sure how to pass the
input objects and receive the output objects.  Is this possible with
WM_COPYDATA in MSVB6?

Another idea is to replace part of the current method with a call to a
VB.NET DLL that I would create.  This new DLL would employ VB.NET's
shared memory and threading to process the temporary objects and
return the output objects before freeing the temporary objects.  Is
this possible?




Sun, 11 Mar 2012 11:23:57 GMT  
 Performance and Freeing Very Many MSVB6 Objects



Quote:
> I am working with a complex legacy DLL written in Microsoft Visual
> Basic 6.  This DLL is called by programs outside my control.  The
> DLL's method takes objects as input parameters, creates very large
> quantities of temporary objects, processes the objects, sets the
> temporary objects to Nothing, and returns other objects as output
> parameters.  There can be hundreds of thousands of objects to free.

If you have by any chance the source for this "legacy Dll" available,
you should try to solve the problem at the root (within the VB6-Code).

VB6-Objects (Class-Instances) are a bit "expensive", since
even small VB6-Class-Definitions have a memory-overhead
of about 110Bytes or so.
Object-Instantiation time is "so so" (usually fast enough for
object-counts up to 100000-300000 objects) - but not
fast enough anymore, in case one wants to create Millions
of Object-instances.

And as you discovered already, the Object-Destroying is the
part in the game which hurts more - here you see already larger
delays, if you are about to destroy Object-Counts of approx.
30000-100000 Objects.

I don't know, what "special actions" the VB-Runtime does
there whilst "cleaning up" an Obj-Instance (compared with
the faster working instantiation/allocation) - the plain mem-
allocs/deallocs cannot be the cause - there are some additional
checks going on - my guess is something like an additional
cycle-ref-check (or maybe additional DllCanUnloadNow-checks)
or something like that.

But since you are talking about *temporary* Objects,
probably created "privately" in your routines, why not
try to rewrite this "temporary part" with different structures,
which "die much faster" than VB6-ObjectInstances.
UDTs come to mind (e.g. organized in an Array) - or
selfwritten "barebone lightweight-COM-objects" as
outlined in the Curland-Book.
Another (easier) lightweight approach is the combination
of UDT-Arrays - and a dynamic mapping of Array-
members (identified over an additionally passed ArrIndex)
within small, few and "on the fly" instantiated Object-Instances,
which are created (and passed) only when they are needed.

Let us know, if you have access to the sourcecode of the
ActiveX-Dll in question - at least for the handling of the
huge amount of "temporary Object-instances" there should
be a solution then, which targets the problem at the root -
resulting in much faster overall-processing and a much more stable
behaviour, compared with "delayed destroying within a thread".

Olaf



Sun, 11 Mar 2012 22:57:39 GMT  
 Performance and Freeing Very Many MSVB6 Objects

Quote:
> If you have by any chance the source for this "legacy Dll" available,
> you should try to solve the problem at the root (within the VB6-Code).

[...]
[Several helpful ideas.]
[...]

Quote:
> Olaf

Thank you!  I have access to the source code but not complete control
of it.  Replacing the current objects with lightweight objects may
take some persuasion, even though "getting to the root" of the problem
should be more elegant and efficient.  I shall discuss these ideas
with colleagues.

I wonder whether VB.NET is faster at freeing objects.  If so, another
"root" approach would be to argue that the slowness of object
destruction in MSVB6 is another reason to port the entire DLL from
MSVB6 to VB.NET.




Mon, 12 Mar 2012 05:10:26 GMT  
 Performance and Freeing Very Many MSVB6 Objects

Quote:
> I wonder whether VB.NET is faster at freeing objects.

This group is for VB6 and earlier(VB Classic). VB.Net and all dotnet groups
have either "dotnet" or "vsnet" in the group name. Try posting your VB.Net
question in one of these groups:





Mon, 12 Mar 2012 05:16:43 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. MSSQL65 and MSVB6 and CR7 Reports ...

2. Performance problems when reading schema data from field objects

3. Performance of the Word VBA Object Model

4. Object Performance

5. performance of FileSystem-object

6. Implement Performance Object in VB

7. Passing Arrays to COM Object Slows Performance

8. Performance of ASP pages calling COM object methods

9. Objects, arrays and performance

10. Creating Objects and Performance

11. COM Object performance question

12. Performance of ASP pages calling COM object methods

 

 
Powered by phpBB® Forum Software