Memory leak - Bulk calculates

Hello everyone -

I've got some VB.Net code using the MapPoint 11.0 COM Objects that are doing bulk calculations of distances between two points.

Here is the basic workflow:
m_oApp.PaneState = geoPaneRoutePlanner

' Ensure we're working in miles
m_oApp.Units = GeoUnits.geoMiles

m_oMap = GetObject(, "MapPoint.Application").ActiveMap
m_oMap.Parent.PaneState = geoPaneRoutePlanner

m_oRoute = m_oMap.ActiveRoute
m_oRoute.Clear()

' Iterate through each row in the data row collection - a row represents an address in the route
For Each dr As DataRow In dsRoutePoints

Dim oLocation As MapPoint.Location
Dim oFindResults As MapPoint.FindResults

oFindResults = m_oMap.FindAddressResults(dr.Item("address").ToString, dr.Item("city").ToString, , _
dr.Item("state").ToString, CStr(dr.Item("zipcode")), "United States")

If oFindResults.ResultsQuality = GeoFindResultsQuality.geoFirstResultGood Then
' The first address seems to be valid - add the waypoint
oLocation = oFindResults(1)
m_oRoute.Waypoints.Add(oLocation)

Else

...

End If

Next

Try
' Calculate the route
m_oRoute.Calculate()

Catch ex As Exception

' Only one waypoint in the row collection - cannot calculate a route
m_oMap.Saved = True
m_oMap = Nothing

ReturnResults.ErrorCode = MapPointStructs.CalculateRouteErrors.OnlyOneWaypoi nt

Return ReturnResults
Exit Function

End Try

m_oMap.Saved = True

' No errors occurred - distance calcualted. Return the results
ReturnResults.ErrorCode = MapPointStructs.CalculateRouteErrors.NoErrors
ReturnResults.DistanceCalculated = m_oRoute.Distance.ToString

m_oRoute.Clear()
m_oRoute = Nothing

Return ReturnResults

What I have found, however is that the MapPoint.exe in the Task Manager is consistantly going up, and up in memory useage. As you can see I am trying to set the Map Object to nothing - but it doesnt seem to be solving the problem.

Any ideas?

Derek

Also try resetting the other objects when you finish with them - eg. the location and result objects.

I assume the memory size keeps growing as it does the processing? If so, setting the map object to nothing after the processing won't have any effect unti it isl finished.

MapPoint also seems to have a lazy garbage collector, and appears to grow to fill the space available when used on a large batch processing job. If you clear your objects correctly, this should tidy itself up when it closes.


Richard

I tried setting the Map object to nothing on each loop - and it doesnt seem to be doing anything (as well as the Location, and Find Results objects).

Also - when the process is finished, MapPoint does not release the memory - it still keeps a good 120 meg to itself. Subsequent iterations of the same batch process do not cause the memory to go any higher...however it does not drop at any time as well.

Setting the Map to Nothing probably doesn't gain anything unless you leave it to the end.

Does MapPoint stay dormant in memory, even when it is closed down? If so, you have a leaky COM object.

When you program finishes, MapPoint will stay big. There are various valid reasons why this might be the case. It has 'taken' memory from the OS to meet requirements, but the bits that are still being used are probably spread throughout this large allocation (or it doesn't know any better).
Maybe this is something for a future version - MapPoint should have a garbage collector that can "shrink" the full memory footprint, and can be called programmatically. It would be slow, but could be called at the end of a load of batch processing.

You may also observe that MapPoint slows down as the memory footprint grows... (again, I think memory is the issue)


Richard

When I destroy the mappoint application object and close the application - all of the memory is released.

I think what I'm going to do is force quit the mappoint application every X batches to release the large memory footprint; then re-open the application object.

I see a similar pattern using the FindResults method. Mappoint increases in memory after repeated calls to that method even though I explicitly close the reference to it. I guess the solution with Mappoint 2006 is to force quit the mappoint application every X minutes to release the large memory footprint; then re-open the application object. This really blows. How would one report this to MS?