ThinkGeo.com    |     Documentation    |     Premium Support

Memory Usage

We are getting to the point in our development that we are looking at performance of our map rendering. I have been watching the memory usage as many of our customers are using rugged computers in vehicles. Rugged hardware tends to have slower processors and less memory.


When running our map application (using MS desktop released the other day, map window size of 995x550) I noticed the memory usage climbs while panning/zooming to about 300MBs. I assume this is due to feature caching (we are not explicitly specifying a cache). As I navigate the memory usage goes over 300MBs, but after I complete whatever I was doing, the memory drops back down to something like 299.


If I full screen the map app (1260x830 map image), then the max memory is around 400MB. After each operation it drops back down to around 399.


Do we have any control over the memory usage? If we specify a geocache, does MS desktop still cache the other layers?


 



John, 
  
 I am a bit confused about your description. The memory will drops back from 300 MBs to 299 Mb s? and from 400 MBs to 399 MBs? I did not see very sharp drop. 
  
 About the cache, we will keep tiles in memory, and it will take 70 MB memory for each overlay. How many overlays are you using against? 
  
 Currently, we did not expose the automatic local cache system out so you cannot change its behavior. We are considering changing it. 
  
 Let me know if you have any more questions. 
  
 Thanks. 
  
 Yale  


Hopefully I can explain this so it makes sense. I think the MS is working correctly in regards to memory usage, I just wanted to know if we have control over how much memory to use. 
  
 OK, when running a mapping application with MS, memory usage is low (50MBs or so). After working with the appliccation (panning and zooming) the memory usage starts to climb. This is expected since more data is being cached (default cache). Once I reach the 300MB mark the memory usage may spike up while I’m doing something, but after the operation is done, the memory usage drops down to AROUND 300MB (typically just under 300, like 297-299 range). 
  
 If I full screen the application, the memory usage will climb to the 400MB mark and remain there. Spiking over during operations, but fall AROUND the 400MB mark. 
  
 Therefore I wanted to know if we had any control over this since we may have customers with 512MB of memory. 400MB would create a problem …unless they didn’t need any memory for Windows (this is a joke of course). 
  
 The performance of our current beta test is very slow with about 400 MBs of shape data. A building polygon layer for Lancaster County, PA is 200 MBs (including your index files) with about 350,000 polygons. It is very SLOW to render this data. 
  
 In comparison, we have been testing TatukGIS’s DK via their trail of the Editor software (we do have the DK 8.x for ActiveX). The editor renders this data very fast and only uses 60MB of memory. I plan to create some videos to demonstrate the speed differences.  
  
 We hope ThinkGeo can get the performance up of the MS or we will have to use TatukGIS. 
  
 Thanks.

John,


Thanks for clearing up the questions!


1) In the latest public release, you have no way to control the size of memory usage for cache system unless you disable it.


We are now on the way to change this, and I think in later release, you will have full control about it.


2) About the performance of loading polygon shape file, I want to make sure how slow it is to render the map? And if possible, you can contact our support to upload the shape file to us, we will figure out why it is so slow because it is so unexpected.


We have another product “WorldMapKit” which will render data over 10 GB while its performance is still acceptable.


Let me know if you have any more questions.


Thanks.


Yale

 



Yale, 
  
 Here is a link to a video showing the performance of the map rendering: 
 onscenexplorer.com/videos/thinkgeo_map_display.wmv 
  
 I will contact support about uploading the data. 
  
 Thanks. 
  
 -John

John,


Thanks for your posts and video, it is amazed you did so great rendering maps!
 
I notice 2 things about the rendering performance:
1) The longest time to render one operation will not exceed 15 seconds, and most of the time will be within 5 seconds. I DONOT think this performance is VERY slow because every time we draw, it also will take some time to save tiles to disk or memory
 
2) It seems the performance will be slow only when the many POLYGON features will be shown, so what you are trying to send us is the POLYGON data?
 
And for better communication and comparison with TatukGIS, can you give me one extent and what time in rendering in Tatuk editor for this given specified extent? Then we can take a very detailed comparison and figure out why it is slow somehow.
 
Thanks again!
 
Let me know if you have any more questions.
 
Yale

Yale, 
  
 I uploaded all the data you see in the video. 
  
 I do think the performance is very slow. When compared to MapObjects, ArcMap 9.3, or Tatuk, it is painfully slow. Our application is for in-vehicle use by emergency responders. When using a GPS receiver the map needs to rotate and refresh rather quickly. I’m concerned that ThinkGeo might not be the platform for our application. 
  
 Along with the video of our application with ThinkGeo…included is a video with Tatuk Editor built in the beta 9 DK. I think you will agree the speed different is substantial. 
  
 onscenexplorer.com/videos/thinkgeo_map_display.wmv  14mbs 
 onscenexplorer.com/videos/tatuk_map_display.wmv     6mbs 
  
 Both applications are using the exact same shapefiles in this demo (which is what I sent you, along with the Tatuk Editor file (so you can try it with trial editor). 
  
 John

John,



  In the next release that is in about a week so we are going to give you full control over the internal caching.  We are exposing it on the overlays themselves.  You will be able to control how much memory you are using.  Thank you so much for the video it helps to see what is going on.  On the performance side of things I would be interested to see the rendering time by layer and overlay.  I have attach some code I whipped up to see where the time is being used at.  After we see what layers and overlays are using up the time we can focus in on some suggestions.  In the next release when we move the caching into the overlays we will also get a better idea on the timing as the Overlay.Drawing time will reflect the caching as now we can't see if that is the slowdown.  



David


 





        internal static string GetMapRenderingTimes(WinformsMap map)
        {
            StringBuilder times = new StringBuilder();

            times.AppendLine("Standard Overlays");
            foreach (Overlay overlay in map.Overlays)
            {                 
                times.AppendLine("Overlay: " + overlay.Name + " Time: " + overlay.DrawingTime.TotalSeconds);
                if (overlay is LayerOverlay)
                {
                    foreach (Layer layer in ((LayerOverlay)overlay).Layers)
                    {
                        times.AppendLine("Layer: " + layer.Name + " Time: " + layer.DrawingTime.TotalSeconds);
                    }
                }
            }
            
            times.AppendLine("Adornment Overlay Time: " + map.AdornmentOverlay.DrawingTime.TotalSeconds);
            foreach (Layer layer in map.AdornmentOverlay.Layers)
            {
                times.AppendLine("Adornment Layer: " + layer.Name + " Time: " + layer.DrawingTime.TotalSeconds);
            }
            
            foreach (Overlay overlay in map.InteractiveOverlays)
            {
                times.AppendLine("Interactive Overlay: " + overlay.Name + " Time: " + overlay.DrawingTime.TotalSeconds);
                if (overlay is LayerOverlay)
                {
                    foreach (Layer layer in ((LayerOverlay)overlay).Layers)
                    {
                        times.AppendLine("Interactive Layer: " + layer.Name + " Time: " + layer.DrawingTime.TotalSeconds);
                    }
                }
            }

            times.AppendLine("Edit Interactive Overlay Time: " + map.EditOverlay.DrawingTime.TotalSeconds);
            times.AppendLine("Edit Interactive Overlay Drag Control Points  Time: " + map.EditOverlay.DragControlPointsLayer.DrawingTime.TotalSeconds);
            times.AppendLine("Edit Interactive Overlay Edit Shapes Time: " + map.EditOverlay.EditShapesLayer.DrawingTime.TotalSeconds);
            times.AppendLine("Edit Interactive Overlay Existing Control Points Time: " + map.EditOverlay.ExistingControlPointsLayer.DrawingTime.TotalSeconds);
            times.AppendLine("Edit Interactive Overlay Resize Control Points Time: " + map.EditOverlay.ResizeControlPointsLayer.DrawingTime.TotalSeconds);
            times.AppendLine("Edit Interactive Overlay Rotate Control Points Time: " + map.EditOverlay.RotateControlPointsLayer.DrawingTime.TotalSeconds);

            times.AppendLine("Track Interactive Overlay Time: " + map.TrackOverlay.DrawingTime.TotalSeconds);
            times.AppendLine("Track Interactive Overlay Track Shapes Time: " + map.TrackOverlay.TrackShapeLayer.DrawingTime.TotalSeconds);            

            return times.ToString();
        }