ThinkGeo.com    |     Documentation    |     Premium Support

64 bit performance

#1

I have recently been testing an upgrade to 64 bit for my app to be able to access more memory.  This has worked great except that it seems like the mapcontrol now draws much slower.  Is there any kind of best practices for efficiently using the control when compiled as 64 bit? Is this to be expected with 64 bit binaries?  What usaully happens is that performance for interacting with the map is normal until it first needs to be drawn on the screen and then just as it is drawn the gui of my app locks up for roughly 10 seconds and processor usage stays at 25% for the entire time (I have 4 logical processors recognized by the os), At that point the map will draw pan and zoom alright, but slower than 32 bit. This behavior stays the same in single tile, hybrid, multi tile, drawing visual, and even direct 2d modes. Which seems odd to me because I thought by default the single tile gdi+ mode was supposed to draw on a background thread (not freezing the gui) and the mulitile mode was supposed to utilize multiple threads for the different tiles (which should cause the proccessor usage to top 25%).  One more odd thing I notice is that if I load and unload the control about 30 times it will turn a corner and begin to perform just as well as 32 bit. Finally, I have tried using ngen to pregenerate native images for my app, but that did not have any effects. Do you have any idea what is going on here?


Thank you in advance for your support,


Steven



#2

I will like to add that our application is starting to randomly hug the CPU at 99% utilization and although we have no hard evidence, all indications point to the map.  It seems as if the map is stuck in a deadlock waiting for something to happen.  Also this usually happens when you have about 10+ layers on the map. 
  
 So to add to Steven’s question, are there any special considerations we should be making when compiling out applications to run on 64 bit platforms?

#3

Hi guys,  
  
 Thanks for posting! 
  
 The only special considerations I am aware of that need to be made for 64-bit deployments are the inclusion of the 64-bit specific System32 dlls that are necessary for special RasterImagery Rendering, FDO Extensions, and Projection conversion. You can find a list of these dlls in the Developer Reference/System 32 folder of your development installation. 
  
 Not to shift the focus from the Map in your application but were there other changes made to your application for its move to 64-bit? 
 If your application was working well as a 32-bit application and no changes were made other than re-compiling as x64 I would not expect a drastic change in performance. If anything performance should be better as you have more memory to address.  
  
 Some recommendations/ideas on where you might look for issues: 
 Do you perhaps have some TileCaching enabled on your 32-bit app and not on the 64-bit? This might explain some of the additional CPU usage as those tiles need to be created, rather than polled from an existing cache. 
 Are you loading shapefiles or other data from over the network, or on a slower sets of disks? 
  
 To see if the performance issues are related to one or just a few of your 10+ layers you might check out the Layer.DrawingTime property that can inform you of the time needed to draw individual layers.  
  
 Let me know what you find.

#4

Ryan, 
 I can safely say we can see a considerable negative performance difference when switching from 32 to 64 bit, changing nothing else in the code (i am just flipping from x86 to anycpu in the project file).  We have options for our users to utilize local shapefiles and bing data over the network, and the performance difference is apparent in both use cases. Unlike Klaus, we are only using 2 to 5 layers with combined shapefile size of under a megabyte. Thank you for your response, and for suggesting the dll fix, however including those dlls in my project did not seem to reslove the issue for me. I don’t know if source code would help any but i may be able to put together a video.   
  
 --Steven

#5

Hi Steven,


Perhaps the best option would be to submit a sample application that can recreate this issue through a Customer Portal Ticket. This way your code is not public and we can try to recreate this on our end. The upload capacity of a Ticket is much higher than here in the forums but we can also setup an FTP upload for you if necessary. If you have any issues logging into the Customer Portal or creating a ticket feel free to give us a call at our main number: Contact Us