2003 ActiveX control in .NET consumes memory when page is updated with setResults.

J

Joseph Gasiorek

I have placed the Visio ActiveX control on a form in .Net and I have a
timer that triggers every 100 m.s.

When the Application initializes:
1) load a document
2) Disable UNDO,EVENTS, and AutoRecovery.
3) Close down all unwanted windows

On the timer Tick:
1)Generate new values to update 3 shapes on the active page.
2)Configure all parmeters for a SetResult call on the page
3)Disable App.ScreenUpdating
4)call SetResults
5)Enable App.ScreenUpdating
6)Use Marshal.ReleaseComObject(object), where objects are created for
manipulation of the page, application (in an attempt to clean up
memory -- it behaves the same way with out this)

If I run this exe, you can see the Memory usage gradually increase (in
task manager). So after 30 minutes my memory goes from 41meg to
75meg, and keeps climbing.

This is the first time I have used the control, I have had tremendous
success in doing a similar thing in a 2002 VSL. Has any one else seen
this memory usage?

Anyone have any ideas?
 
J

Joseph Gasiorek

I have placed the Visio ActiveX control on a form in .Net and I have a
timer that triggers every 100 m.s.

When the Application initializes:
1) load a document
2) Disable UNDO,EVENTS, and AutoRecovery.
3) Close down all unwanted windows

On the timer Tick:
1)Generate new values to update 3 shapes on the active page.
2)Configure all parmeters for a SetResult call on the page
3)Disable App.ScreenUpdating
4)call SetResults
5)Enable App.ScreenUpdating
6)Use Marshal.ReleaseComObject(object), where objects are created for
manipulation of the page, application (in an attempt to clean up
memory -- it behaves the same way with out this)

If I run this exe, you can see the Memory usage gradually increase (in
task manager). So after 30 minutes my memory goes from 41meg to
75meg, and keeps climbing.

This is the first time I have used the control, I have had tremendous
success in doing a similar thing in a 2002 VSL. Has any one else seen
this memory usage?

Anyone have any ideas?
Click to expand...

I have investigate this more and found that a SetResults(that changes
3 cell values) or 3 seperate calls to the cells.ResultIU cause massive
page faults. By commenting out only the set result or 3 seperate
calls, then no page faults exist and the application is well behaved.

So why do writes that update the drawing cause page faults?
 
M

Mark Nelson [MS]

I believe the culprit here is garbage collection under .NET. Visio uses an
internal object list to track objects for automation. In COM programming,
releasing an automation object causes an immediate release from the internal
list. In .NET programming, the object doesn't go away until garbage
collection takes place. This can dramatically extend the lifetime of these
objects and result in the type of memory consumption you are seeing. I
believe the prescribed workaround is to force garbage collection to take
place, though this goes against the .NET philosophy of managed code.
 
J

Joseph Gasiorek

That maybe true, but I have tried to force a GC.Collect() and no
changes occur.
I have looked at article 839079 and improved the process by removing
the gradient fill object, but that only improved my CPU consumption.

What I notice is that the Applicaiton has a tremendous amount of PAGE
FAULTS being generated. When the app runs, it is 40meg and I have
384meg available, but task manager keeps reporting 200-1000 page
faults per second. These faults are directly related to how fast I
change the drawing by updating a shapes value. Why would a page fault
occur if there is 9X the applicaitons size available in TRUE memory?
Is it a fact that the control renders a new metafile for each change
in the drawing?

I also note that as the page faults increase in frequency, so does the
application's memory(leading to a 1.2gig app on and over night run).

For clarification, Each COM object in the control is assigned and
cleaned after each use with a Marshal.ReleaseComObject() and I have a
GC.Collect at the end of the timer. With the timer code remaining the
same, if I comment out the page.SetResults code that does the shape
update, then the page faults stop and memory remains constant. So
with all of careful .Net to Unmanaged COM cleanup, it appears as if
the "CONTROL" has a problem with memory leaks, or for some unexplained
reason it is causing a page fault which leads to memory increases.

With this info, any ideas Mark?
 
M

Mark Nelson [MS]

Hi Joseph,

You've obviously pursued this issue through many channels including the
newsgroups. The product team is investigating the issue. It seems to be
the problem identified in article 839079, but the published workaround does
not solve the complete problem.

--
Mark Nelson
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Top