ThinkGeo.com    |     Documentation    |     Premium Support

Edit performance proportional to memory usage

#1

Editing performance is pretty good now in the demo app (TrackAndEditShapes). However, in my own program, the performance isn’t so hot… points that are dragged lag the cursor ever so noticeably. So I decided to create a test program, containing a single wpfMap inside of a Window, and I loaded a shape file. I loaded the same shape file into my own software. Side by side the test program greatly outperformed my software in editing the same map. So I chopped things out of my program, and eventually, performance started to improve. hmm… so then I decided to try using up some memory in the test program. So I allocated memory for a million “buttons” - didn’t add them to the window… just created them. Editing performance in the test program dropped considerably. 



So, is this normal for WPF? or some sort of bug in wpfMap? it seems pretty easy to reproduce. I thought it might be related to the number of controls in my Window - but the killer in my program is when memory is allocated for the view-models (which contains about 20 observable collections), and obviously these aren’t wpf controls.



any thoughts? 

#2

Did a bit more experimenting on this. It appears to be the ObservableCollections in my ViewModel which impacts most on performance- not quite certain, but it appears to be. I’m wondering if during the editing process (i.e. moving points in a polygon), there might be repeated searches in the logical tree?? It can’t be the visual tree as I’m not adding any controls to it. 
  
 Anyway… my client is not too happy with editing performance… be nice to find away around this. 
  
 thoughts?

#3

Hi David, 
  
 That’s very strange because the redraw speed only related with the controls which in the application window. We haven’t thought any reason about that. 
  
 This setting may not work for your issue but just have a try. PolygonTrackMode = PolygonTrackMode.LineOnly;  
  
 If possible, please sent us your test program so we can help you try finding the reason. 
  
 Regards, 
  
 Don

#4

Attached is a sample project which outlines the problem (you will need to change the hard coded paths of the shapefile and projection file). When the project first runs - moving a point is very fast. If you click the checkbox at the top of the window - you will see performance degrade significantly (moving points is sluggish). In the software I’m working on, its the creation of the view model which seems to kill the performance - so I’m not creating visual controls in that case.



Any ideas? My hunch is that this is quite fixable.

TestThinkGeo.zip (120 KB)

#5

Hi David, 
  
 Thanks for your project. I reproduced the issue succeed and did some test based your project. 
  
 1. I think that’s not related with ObservableCollection or Button control, I replaced them with Collection<String> and everything still be slow. 
 2. It’s not only for EditOverlay, I remove EditOverlay and TrackOverlay, only show all features in ShapeFileFeatureLayer, after I add 10000000 strings, the pan speed obviously slow. 
  
 So I think the mainly problem should be after many memory takes, our map slow. I will talk with developers for make sure whether it’s issue or how we can handle it. 
  
 Any question please let me know. 
  
 Regards, 
  
 Don 


#6

Thanks for looking at this. I’ll wait patiently for a reply! :-)

#7

Hi David, 
  
 Thanks for your patience, anything new will be uploaded here immediately 
  
 if you have any more question , please feel free to let us know. 
  
 Best Regards 
  
 Summer

#8

Hi David, 
  
 We have enhancement code for that, please get the version 7.0.39.0 or higher version for that. 
  
 What you only need to do is set a new property like this: 
  
 wpfMap.GcCollectionMode = GCCollectionMode.Optimized; 
  
 Regards, 
  
 Don

#9

Hi Don, 
  
  Will this optimization be applicable to the whole component? or only to the EditInteractiveOverlay? 
  
  Some customers complained lately that after two days of use the application was getting slower and slower, and we fixed it installing old 6.0.260 dlls instead of 6.0.365. and now I’m wondering if this fix might also help in the rest of the component, not only EditInteractiveOverlay 
  
  Regards, 
  
 Carlos

#10

Hi Carlos, 
  
 This update works for the whole component but not only for EditInteractiveOverlay. Your GC Collection Mode setting related with any mouse or key event. 
  
 But if 260 works for it but 365 not, I think maybe that’s not caused by the same reason. 
  
 Regards, 
  
 Don

#11

Hi Don, 
  
  Will it cover If we call WpfMap.ZoomTo, or zoom by double clicking the map? 
  
 Carlos

#12

Thanks very much for that - performance is fantastic - I was a bit uneasy about the point markers hiding when moving points - but having used it, its not a big deal - I suppose it would be nicer if there were still there - but I’ll take the increased performance any day!!

#13

Hi Carlos, 
  
 It don’t cover ZoomTo because the ZoomTo function don’t have this issue before. 
  
 It cover double click operation. 
  
 In fact, this change only works if your map include any InteractiveOverlay. 
  
 Regards, 
  
 Don

#14

Hi David, 
  
 I am glad to hear that works for you. We will do our best to keep enhancement our map control for better performance follow user’s requirements. 
  
 Regards, 
  
 Don