ThinkGeo.com    |     Documentation    |     Premium Support

Overall component performance

#1

     Recently a customer showed me the application of our competitor that is based on c-map chart engine. It was amazingly fast when moving arround the map (zooming, panning, etc), bud not slightly faster, I mean orders of magnitude faster than our MapSuite based applications (both WPF and WinForms).


    Even ussing TileCache the navigation arround the map is not as smooth as with other gis tools such as google maps, openlayers, etc, what I cannot understand knowing that in our case the map tiles is precached in the local drive while openlayers streams it from the internet.


   Seeing that the most voted feature at ThinkGeo Enhancement Tracker back in 2011 was preciselly Improve rendering performance, do you have any plan to improve the component architecture in any way to speed it up? (in addition to all you already done till now, that I have to admit is a lot since version 4.0 when we purchased first time the dev license)


  Do you have an idea how is it possible c-map is so lightning fast in comparison?


  As aside question but related to the previous, some times when moving arround the map, maybe in uncached zones, but some times even in cached ones, the main thread gets frozzen for a few seconds, and pausing the execution at this point VS shows the stack is in WpfMap internal methods. Have anybody else experienced this?


 Regards,


Carlos



#2

Hi Carlos, 
  
 Thanks for reporting the problem, we have downloaded the C-map you mentioned, now we are trying it and doing some investigations, such as it’s native or managed code based, how does it behavior etc. Also I have talked it with our development team, they are also doing some research on it. I will update all the anwsers here once we get something out. Sorry for the Inconvenience. 
  
 Thanks, 
 Johnny

#3

Hi Carlos, 
  
 Thanks for reporting the problem, seems like the C-map doesn’t provided a public trial version for download, We have contacted them now and waiting for the download link. So that we can  try it and do some investigations, such as it’s native or managed code based, how does it behavior etc. Also I have talked it with our development team, they are also doing some research on it. I will update all the anwsers here once we get something out. Sorry for the Inconvenience. 
  
 Thanks, 
 Johnny

#4

Hi Carlos,  
  
 We contact their support and sales, but seems like it’s hard for us to get a trial version of C-Map, Is it possible for you to provide us a demo showing it? you can send it to forumsupport@thinkgeo.com. 
  
 As far as I guess, C-map should a pure native C liberary, Strictly it perform a bit better than the managed liberary. Anyway, I’m still contact their region sales now, and waiting for your furhter information. 
  
 Thanks, 
 Johnny

#5

Hi Johnny, 
  
  I sent you an email with a c-map application installer. I guess so it’s a native C library. 
  
  Hope it helps 
  
 Carlos

#6

Thanks Carlos, we have got your email, and are going to do a further investigation later. 



Thanks, 

Johnny



#7

Carlos, just shot you an email but wanted to put in my few bits here.  There is no way that a managed application can match the performance of a native C app, just like there is no way an application written in C will match one written in Assembler :)    Even a C++ application will not match the performance of a C app.  In terms of application performance, C is king here but we consciously use managed languages like C# and Java because they reduce our overall cost of development and allow us to focus on solving the domain problem. 
  
 I do not think ThinkGeo can do much about this difference in performance as long as the underlying component is native .NET.   I agree that MapSuite performance can be improved but to the same extent as you will have in a native application, that is not a realistic expectation.

#8

Hi Klaus, 
  
  Of course I expect some performance penalty because of managed code, but not that much. Some times there are orders of magnitude in the difference, and some times the component shows a very bad performance without any explainable reason; For instance yesterday it took 25 seconds to load 32 uncached tiles, having only one 25 Mb shape file with shorelines as background. It was in a Core i7, 8GB Ram, SSD disk equipment where CPU nor I/O was showing a special high usage (cpu were under 20%). 
  Even strangest was that it ran much faster in the same laptop after switching from the nVidia 2GB dedicated RAM GPU to the integrated card (I suppose it was an Intel HD, but I didn’t check it). I switched back and forth several times as I couldn’t believe it was faster without the nVidia card. 
  
  Anyway, it takes more time to load the tiles than other solutions, not even native C, but for instance OpenLayers which loads the tiles from the internet. I know OpenLayers would have OpenStreetMaps tiles pre rendered, but still it’s needed to transfer them over internet, where MapSuite have them cached in the local disk. Now we use SSD disks as they make a big difference as the map component is very I/O intensive, but still it should be faster. 
  
  I recently spot a performance analysis profiler in VS2012, but I’m still learning how to use it. For sure it will aim me with more data I will be able to use to help on improving the component overall performance

#9

Hi Guys, 
  
 There are some possible reasons about Wpf edition performance, as follows 
 1. WPF chooses the balance between Performance and user experience. So, WPF is not faster than native c, but the user experiences is better than native c. 
 2. We have made a test sample with Texas road data which is more than 300M, it takes 11 seconds to render the whole map. The big difference happened between our sample and your sample, I think it might be following points: 
   a.  Sometimes, multi-tile drawing  is not faster than single tile, because some features are drawn multiple times on different tiles. For example, if we have a polygon shape, and zoom to very deep, one of the polygon covers many tiles so that we need to draw the same polygon multiple time in these tiles. 
   b. Different styles can affect the performance. 
   c. Different drawing quality affects the performance. 
   d. “LockLayerMode” property can be set to Lock / DoNotLock, in Lock, the tiles were drawn one by one, and in DoNotLock, the tiles were drawn on the same time, so you can set LayerOverlay.LockLyaerMode to the two modes. 
 3. Do you mind send the test sample data to us so that we can create the sample to reproduce this issue. 
  
 Thanks, 
 Edgar

#10

Hi Edgar, 
  
  I was willing to create a simple sample with my shape files that I thought could be a reason (some are 30 Mb size), but I just saw other customer complain on performance gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/39/aft/11119/afv/topic/Default.aspx but with online bing maps. So now I don’t understand why it affects the zoom level to the performance. May it be an issue with TileMatrix trying to alloc more memory with every zoom ampliation? 


#11

Hi Carlos, 
  
 Thanks for providing a demo to us, can you also attach some detailed information and the configuration of your test machine forllowing the sample? Please check other anwsers at gis.thinkgeo.com/Support/DiscussionForums/tabid/143/aff/39/aft/11119/afv/topic/Default.aspx#36555. 
  
 Thanks, 
 Johnny

#12

Hi Jonny, 
  
 I just sent you a sample with our actual loaded data to forumsupport@thinkgeo.com  
 The bad performance is observed in any configuration, I tested it in a Core i7 @ 2.8, 8 Gb Ram, SSD disk with similar results. I don’t find the nVidia GPU makes any big difference. 
  
  Please advise, 
  
 Carlos

#13

Carlos, 
  
 Thanks for your demo, we have got it, now we are still debuging it and run the performance tests. Any workable solution I will update it here. 
  
 Best Regards, 
 Johnny

#14

 Hi Carlos,



After a further investigation, we find there are 2 places that we can improve the performance based on the demo you show to us. Here are the details:



        
  1. We did some enhancements and improvements in our code, would you please get the updated version 6.0.332.0 or later to have a try? (Note: the new package is still in the building of daily build, maybe it’s unavailable now, please wait for hours.)

         

    2.     
  2. In the demo you show to us, I suggest put the “KmlFeatureLayer” into another Overlay instead, because “KmlFeaturelayer” takes a long time to do the query, putting it into another overlay will make it run in another thread and doesn’t affect the user experience. Attached is the modified code, please check it out.


After these 2 modification, the speed improved from 6300 ms to 910 ms when using TileType as SingleTile on our end (2.83G CPU).


 


Hope it helps and best regards,


Johnny



Post11071.KmlFeatureLayer.vb.txt (1.67 KB)
Post11071.MainWindow.xaml.vb.txt (27.2 KB)

#15

Hi Johnny, 
  
  I downloaded 6.0.335.0 and made some performance tests. Only by upgrading the dlls (from version 6.0.260.0) I can see a initial (ZoomLevel 3) load of uncached map goes down from 24 seconds to 11 what is nice, but but for the deeper zoom levels (scale 100.000) I can’t see any difference. 
  
  If I switch to SingleTile thought, the difference is stunning!, It loads really fast. It’s a pity SingleTile does not support WrapDateline mode, that is a must in our case. 
  
  Splitting the KmlFeatureLayer in a different overlay creates other problems also, as the polygons are covered by the shape files data, so map is not displayed properly. 
  I know SingleTile does not use TileCache, so this is not a problem, but if it did, how could I handle having different overlays to store in the TileCache? 
  
  Why is SingleTile so fast compared with MultiTile or HybridTile? What else can I do to speed up the overall performance? 
  
  Thanks in advance, 
  
 Carlos

#16

Hi Carlos, 
  
 The reason for same speed in scale 100,000 is that when in scale 100,000 the features count to be drawn is much less than these in zoomlevel 3, so although every feature in old dll is slower than the new dll, but as the features’ count is small, therefore the sum of slow time in old dll is not long enough to be observed. 
  
 About splitting KmlFeaturelayer, it should work because after KmlFeatureLayer is moved to another overlay, wpfMap.Move…() could be used to make sure that the polygons not be covered by the shape file data. Another thing for you information is that though KmlFeatureLayer and shapefilefeaturelayer are put in the same overlay in your demo, the KmlFeatureLayer will also be covered by shape file data in your sample, because the KmlFeatureLayer is added before ShapeFileFeatureLayer. 
  
 About handling different overlays’ cache you could set every overlay’s cache id and directory separately. 
  
 About the singletile being faster than the MultiTile and HybrideTile, the reason is that in multitile every tile needs to find its own part of a shape, so in multitile and hybirdtile the one shape will be queried twice if it covers two tiles, but in singletile, this shape will only be queried one time, so, singletile has shorter query time to make itself faster. 
  
 Hope it helps 
  
 Johnny 


#17

Hi Johnny, 



In the sample the shapefile is drawn on top, but the background is drawn before, so I have background, kml files and then shape file covering kmls only partially (as desired). If I split it in different overlays, what I see is that the kml is drawn for a tile, and then seconds after is overdrawn by the shapefiles with the background, so effectively being hidden. I could separate the background to other overlay thought, but isn't it costly to have many overlays? 



I understand the difference between MultiTile/HybridTile and SingleTile, but is a pity not having the advantages of both. Do you plan to include WrapDateline functionality in SingleTile at some point? or maybe it could be possible to make only one query in the Multi/Hybrid and then split in different threads the rendering? 



If non of the above improvements are in the roadmap. What else can I do to improve the overall component performance in a substantial way? 



Carlos



#18

Hi Carlos, 


To move background to other overlay is a good idea, this will have a Synthesized highest performance.


About WrapDataline functionality in single tile and one query in Multi/Hybrid, sorry to say that we don't support WrapDateline in singletile and One query in Multi/Hybrid for now. You can vote this enhancement to helpdesk.thinkgeo.com/EnhancementTracker. This captures the enhancement request and provides visibility to the customer letting them know that the enhancement is on a list somewhere and that popularity of the enhancement helps set the priority of when the enhancement would be added to the product. This option doesn't carry any cost for you.


We suggest you to try to move background to other overlay, this should fulfill the functionality and be faster.


Hope it helps


Gary



#19

Hi Gary, 
  
  What does “Synthesized performance” mean? 
  
  Sorry for saying, but EnhancementTracker is completely useless. Most of the enhancements are back 2011 when you released it, and many are still open even with high number of votes (see Improve label placement algorithm for instance), no body is using it from 2011, and the customers don’t really know what the roadmap is and what things are being doing or not. 
  To say vote it in the EnhancementTracker is like saying “yes, yes, write it there and don’t bother us with this feature, we will see if it’s feasible or not in the next decade”. 
  
   The issue is still the same, the component performance is very poor, and I’m desperate as I don’t know what else to do. If you compare it with any other solution even online ones (GMaps, iOS Maps, Bing, OpenLayers, etc) no other takes 20 seconds to load the tiles on view (perhaps with poor internet connectivity, but we in my case the data is in local drive!!!) 
    I know MapSuite is .NET code, and has nothing to do with native C as in the C-Map engine I show you, or any other mapping system such as MaxSea, Orbmap, etc, but still the difference is too high to be understandable by means of programming language / technology. It must be something can be done for sure, perhaps is not your main priority now, perhaps we should include it in EnhancementTracker as well (in fact it is already there, the most voted indeed with 62 votes, but you close it with an odd extension in 5.5.14.0 or something like that) 
  
  Perhaps is just that the component is in the maintenance stage now, and we should not expect the old days kind of great improvements from now on. 
  
  Thanks anyway. 
  
 Regards, 
  
 Carlos

#20

 Hi Carlos,


 
About the enhancementTracker, we are sorry about the inconvenience, but if the task will take a long time to do, we will put off it and do some tasks which have higher priority. If you want an enhancement in high priority, please contact support@thinkgeo.com or sales@thinkgeo.com to request.
 
About the performance issue, as we mentioned above, in multitile mode, the kml featurelayer will be queried multiple times and slow down the speed, however, after setting the tile cache, the speed is very fast. Here is a video screencast.com/t/LxeupvCbiYs to show you about the performance with tile cache(I didn't change anything on the code), as you can see in the vedio, I zoomed in to draw the map and generate caches for every zoomlevel, and when I zoom out(at 1:20 in the video), the map was drawing in a very fast speed.
 
I'm curious why the performance is bad after using tile cache on your side(especially you are using SSD), could you please make us a vedio? (Maybe I was in a different extent). And here attached is the performance test result, you can see the performance is pretty good with tile cache.
 
Here are some questions to you,
 
1. It is not clear to us that which part of performance is unacceptable for you, the drawing time before cache generated or the drawing time using cache?
 
2. I noticed on every time the program startup, the cache folder would be deleted, is it necessary to delete it every time when starting the program? Or you have to do it in some scenario we don't know?
 
Thanks,
Edgar
 

TestResult.txt (1.49 KB)