ThinkGeo.com    |     Documentation    |     Premium Support

Rendering performance regression in 3.0 beta

#1











Hi all, 


 


We’ve evaluating Desktop 3.0 beta for the purpose of upgrading from the 2.25 version used by our application right now. Many new features in 3.0 are compelling reason to upgrade, despite the port to the new API. I was glad to see elsewhere on this forum that performance is an important metric for the MapSuite team, because it’s certainly very important to us. Particularly, this is the reason we’re held back at v2.25 – all subsequent revs introduced various sorts of rendering performance regressions (see ticket 1268 for details, the benchmark script and data files were supplied with that issue). 


 


Benchmarking v3.0 beta reveals mixed results: loading times are improved, but rendering performance degraded compared t0 v2.25. Our benchmark script uses 8 mrsid tiles, 16MB each, and measures loading and 10 typical rendering operations, inc. zoom-in, zoom-out and pans. Averaged (pretty consistent) timings are:


 


1st Load: 9.95s in 2.25 vs 11.8s in 3.0


2nd Load: 6.09s in 2.25 vs 4.18s in 3.0


Script: 13.3s in 2.25 vs 26.6s in 3.0 


 


One change we had to make to the script in v3.0 is to call Refresh() explicitly, while 2.25 refresh happed automatically after each extent change. I understand this is done to provide a better control and avoid unnecessary refreshes, but it doesn’t help performance. 


 


Questions are: are there any ways to improve performance? Are there any known performance issues in the beta which are to be resolved in the final release? 


 


Thanks!  




#2

Fedor, 
  
   We are very concerned with performance.  When we set out to build 3.0 perf was on our mind.  At the same time we had to strike a balance between that and a new solid API where things are a bit more distributed.  In the 3.0 structure we have more extensibility which mean more virtual methods and more objects to go through on the stack. We wanted the logic to be distributed more to the objects where it made sense for the work to happen.  We also wanted to focus on safety so we have very extensive parameter checking on all public API which slows things down a bit.  This includes checking on virtual core methods as well so there is quite a bit of double checking going on, but its the safest way.  In the beginning I would have predicted the overall time would have been much slower due to many of these items.  What we found instead is a speedup in most cases due to a much better design, a design which pointed out glaring problems and made them easier to find and solve. 
  
   The good news is that with 3.0 we are in a much better position to identify bottlenecks and fix them.  Also due to the new extensible nature of the object model we are in a great position to write customer  centric objects by overriding certain API to make speed increases based on specific specific scenarios.  We are also in a good position to share that code with you so you can see the inner working of some of the objects.  Since we have your data and scripts I would be happy to add these to an issue and have someone look at them.  Currently we are in the last stages of releasing the new beta of the Desktop Edition and all hands are working at full tilt.  After the release, around the 22nd, I can have someone take a look at your specific issues.   
  
   If I were to take a stab at how we would speed things up for you I would guess the following areas.  First I would like to take all the parameter validation out of the main code path for your test cases.  Second I would look at the Mr Sid specific RasterSource and see if there is anything going on with getting the data from the third party MrSid dll.  I would then look at the GeoCanvas you are using.  Are you working in Winforms or WPF?  Maybe there is some conversion or scaling going on we can avoid.    On the drawing itself I know that the next beta will draw the maps on a separate thread which should help out but I am not sure if that is what it did in the last beta.  In any event hooking up the good old perf monitor should make all things clear. 
  
 David

#3

Hi David,  
  
 thanks for the insight and the quick reply. I appreciate the challenges of developing a complex component library, and will gladly work with your team to improve the quality of the final release. We want you to succeed as much as you do. 
  
 I’d love to know how overwrite certain APIs to improve speed in specific scenarios, looking forward to that code. And we’re using WinForms components, not WPF.  
  
 So let me share some observations – maybe this will point to some things which can be considered for the 2nd beta:  
  
 1. In v2.25, when we add manual (unnecessary) Refresh() after every extent change, the performance is exactly the same as in v3.0. This may be a coincidence, but it may be a sign of an inadvertently doing something twice in v3.0 Refresh().  
  
 2. back in the v2.x days when I was looking at the performance issues, I was comparing perfmon counters between MapSuite and LizardTech viewer on the same mrsid file, doing roughly the same operations. One standout was the amount of physical I/O: MapSuite’s about 5x of LT. 
  
  Thanks!

#4

Fedor, 
  
   Looking into things I found one area that may be slowing things down.  When you have a number of MrSid files and you load them as a separate layer there is a number of duplicate things happening.  One thing is that if multiple files show on the screen at the same time we need to create a bitmap the size of the screen for each layer.  The request is sent to the Mr Sid dll and most of it may be blank.  We then overlay all the layers on top of each other.  If your map is 1000x1000 then for each layer we would need to create a bitmap this size for each raster layer that has any part of the image on it. 
  
   What I think we are going to do is to modify the MrSidRasterLayer and RasterSource so that it will take an list of Mr Sid files at one time.  This way we can optimize the calls to MrSid’s dll. And stitch the results together.  This should save allot of time when you have like your example of 16 tiles and you may zoom out to see all 16 at one time.  I just wanted to share the things we are finding.  We will look more into this over the next week or two. 
  
 David

#5

Fedor, 
  
   Is your data mainly raster? 
  
 David

#6

Hi David,  
  
 sorry I didn’t see your question earlier. And I don’t have a definitive answer. It’s certainly not all raster all the time – we display up to a dozen shape layers at different times depending on zoom level and configuration. But it’s the raster data which takes the heaviest performance toll and which we can’t control, unlike the streets shape, for instance, where we can only show certain labels.  
  
 Hope I answered your question, and I’ll be monitoring this forum closer (now that you’ve released beta 2…)

#7

Fedor, 
  
   Thanks for the info.  I think we have a strategy that can speed up the MrSids imagery and we could release it outside of the main release as a plug-in.  Let me find out the details and I will let you know when we can tackle this.  If you wouldn’t mind being a guinea pig for this and give us your opinion. 
  
 David

#8

I wouldn’t mind that – for the first implementation. Beyond that, what concerns me is the long-term supportability. Perhaps you can alleviate that by sharing the details of your strategy and implementation. What would be so specific in that plug-in that prevents it from being released in the mainstream?

#9

I also noticed a performance regression in namely displaying MrSid files that I hadn't gotten to mentioning yet.  I think any speed enhancements you might have for raster layers would probably be desired by everyone.


- Chad



#10

Fedor, 
  
   The strategy for the plug-in is to make it main stream eventually.  When we have a plug-in that is developed outside of the release then we do not have to adhere to all of the release guidelines.  Once code goes into the release we can never make breaking changes, re-organize things etc.  Also to get into the release it needs documentation, samples in all the various products, Web Service, Desktop in C# and VB for VS 2005 & VS 2008.  It also need to pass FXCop, StyleCop, and our own internal standards.  All of the APIs have to be reviewed by our architects to follow standards and we have to build a suite of unit test cases for it.  Allot of things to slow the process down to get you something to try. 
  
   Once we know we have a good design that has been tested in the real world by a few people then we start it down the path of being integrated into the truck.  I hope this makes sense. 
  
 There are two other cases we make plug-ins that don’t apply here but I will mention them anyway for completeness.  The first is when we the functionality has a dependency that we do not wish to include in the main release.  This is usually for niche functionality and we rather not have the default Map Suite assembly carry around lots of dlls.  The second case is where users have a need to functionality that we think no one else will use.  Really custom stuff that we can help with but we fell will never go mainstream.  We do this not to muddy up the api with more classes etc. 
  
 David

#11

Could you please keep me in the loop of this add on too?  I recall there was some sort of flag added that was in 2.x called IsFastRendering or something like that for Image Layers, that i remember when turned on made a huge difference.


Thanks, Chad



#12

I’m happy to hear that your engineering team is following such rigorous and mature release standards! This means in the future threads like this will be extinct, because the unit test #12547 MrSidTilesRenderPerformance() will catch all the problems before the bits go to QA… 
  
 Until this happens, we’ll gladly validate your experimental code in whatever passes for the real world in our dev efforts. To help with the planning, when can I expect the 1st drop?

#13

Guys,


Good news! We figured out that problem, just copy the attached dll to C:\Windows\System32\MapSuiteGeoRasterX86\ and override the existing one; you will get much performance improvement. 
 
Please have a try.
 
Ben.

351-MapSuiteMrSidsX86.zip (22.3 KB)

#14

Fedor, 
  
   We found that the issue was in the small glue C++ wrapper.  This is the DLL that exposes the Mr. Sid C++ library to our managed stuff.  There isn’t much code there but that is where the problem was.  Specifically it was related to us calculating the correct level to fetch from the Mr. Sid file.  With the incorrect code we always retrieved a much larger image than what was necessary then we scaled it down.  Because of this there was allot more work to do and more IO to the image file as you pointed out. 
  
   Note that even though we fixed this issue it is still a bit slower then the LizardTech viewer.  This is because the viewer only allows you to zoom to the level in the MrSid file and then multiples thereafter.  Since we allow zooming to any scale we have to rescale the image which takes a bit.  Having said this the rescaling of a smaller image is much faster than what we were doing before.   
  
   Try the bits we attached and let us know what you think.  If everything is good we will update this for the next release. 
  
   Also I think in Ben’s post he said override where he meant overwrite. :) 
  
 David

#15

Chad, 
  
   The property you are talking about had to do with loading TIFF files specifically.  The default .NET load is a bit slow for large files as it does some locking.  The LoadFast was a Win32 API call that loads it much faster.   
  
   In the 3.0 version for GeoTiff we have a new GeoTiffRasterLayer which uses a new method of reading scan lines which is much, much faster then the 2.0 implementation.  If you have Tiff files I suggest you try the new class. 
  
 David

#16

Great glad to hear you found the problem.


Im still on beta 1, the only file i have is MapSuiteMrSids2005.dll.  Also i have a C:\WINDOWS\system32\MapSuiteGeoRasterX64 directory with a MapSuiteMrSidsX64.dll in it.  Is this something that was added in beta 2 or am i missing something with where the X86 file is located?



#17

Chad,


You are right and that's new in beta 2. Anyway, here is the dll for Beta 1 (3.0.131), just replace the existing one in your "C:\WINDOWS\system32" and have another try.


Thanks,


Ben.



354-MapSuiteMrSids2005.zip (20.5 KB)

#18

Solid.  It seems to have improved the rendering quite a bit.  Keep up the good work.


- Chad



#19

Great! We will include this new dll to the coming release (will be available tomorrow) in which you can also turn off the multi-threading. 
  
 Thanks, 
  
 Ben 


#20

Fedor, 
  
   I haven’t heard anything from you on this.  I know the Mr Sid rendering perf was a big deal for you.  Did you have a chance to test this yet?  By the way this new dll is shipped in the latest beta that was posted yesterday. 
  
 David