Performance with Large Map Sets

[MichaelErlich]

After running more tests, we have some questions on the expected performance given the following results listed below.  The map packs that we have been using so far are on the lower end in size so we created a more typical map pack of what customers will use consisting of merging TeleAtlas data for the U.S. states of: AK, AZ, CA, CO, HI, ID, MT, OR, NV, NM, UT, WA, WY and having the data converted from a shape file to a file based gdb.

First set of tests were run on a machine with the following specifications:
Dual Quad core 2.00GHZ Xeon, 8GB RAM, 64-bit Win7

The mpk file took 3 minutes to load on first run, and 2 min 10 sec on subsequent runs.  It was very sluggish when drawing, but performed better when zoomed in to street level than tile packs.

The tpk loaded ok, but became more and more sluggish the more we zoomed in.  At the streets level, it could take around 30 seconds to display the tiles and at the lower zoom levels, it would leave off from 2 tiles to over half of the tiles.  Changing the zoom and then zooming back may display the missing tiles or start missing a bunch of different tiles.

Second set of tests where on a machine with the following specifications:
Dual Core 1.6GHz Atom processor, 2GB RAM, 32-bit win7
NOTE: that our typical client will run our software on a single core atom processor, 1-2GB RAM, win xp or win7.

The mpk took 8 minutes to load while keeping the CPU pegged at 60% the entire time.  Subsequent loads took 7min 30 sec.  It took several seconds to 30 seconds to load the display when moved or zoomed.

The tpk has similar results as above, except that the 30 second load time for the tiles moved to 60 seconds and the cpu was pegged anytime the map was moved or zoomed.  This is concerning since this will be needed for navigation and with keeping the vehicle center screen, the map will constantly be moving.

Our main questions are: Are the above results expected for the size of the map data that we are attempting to render?  Is the control intended to be used with the ???standard??? tough book hardware specifications outlined in the above second set of tests?  If the above results are expected, are there plans to increase the rendering performance of this control in the near future?

I have placed the map data on our FTP.  Since Mike Branscomb is out of town, if anyone from ESRI would like to look at the data, provide me an e-mail address and I can provide the ftp credentials.

Regards,
Mike

[RalfGottschalk]

Hi Mike,

Regarding MPKs, we have noticed and heard complaints that the larger the MPK and the more complex the data the longer the load time.  The first time you open a Map Package the data needs to get unpacked, currently in your user profile.  We are planning on including an API to allow you to control this.  This does take time to load though.  Each subsequent load should just load the data, and not need to unpack, that is why you see a difference between the first load and each load after that.  Do you get the same performance hit if you reference the data in the MPK instead of including it?

7 minutes on the slower machine is pretty slow.  There is always going to be some overhead when starting up a local service.  But we do want to minimize this hit as much as possible.  And developers could minimize the impact of it on thier users by dynamically enabling functionality as it becomes available.  We are currently researching ways to improve the performance and see where the bottlenecks are, and do what we can to reduce them. 

Regarding the TPKs, the current implementation of reading the TPKs has to load the TPK into memory in order to draw the tiles.  This is problematic if your TPK is fairly large and you don�??t have a lot of RAM.  We are looking into a better way to do this so you don�??t run into this problem.  For now, the workaround it to use 7-zip and extract the tiles out of the TPK.  You can then reference the tiles by pointing it to the folder that contains the conf.xml file.  So if this file exists in �??Yosemite�?� point the LocalTileCacheLayer to �??C:\..\..\Yosemite�?�.

You can e-mail me the FTP credentials, and we can use this data in our performance research.  rgottschalk@esri.com

I do appreciate your testing, feedback, and willingness to providing the data that you are trying to work with.

[MichaelErlich]

Thanks for the info.  Just did a quick test with unzipping the tpk file on both platforms described above and that made a world of difference.  On both, the results have met our expectations.

The two tests that I will try to perform this week are:
1) try your advice on referencing the data in the mpk.
2) test tpk with overlapping layers.  Our customers require the ability to turn layers on/off and we are investigating which map type will work best to handle this.  We can either using an mpk, or overlapping tpk files.  The overlapping tpk have been verified to work, just need to test performance with larger map sets and determine how many layers can be used to provide optimal performance.

I will keep you informed with our results.  Also, let me know if you find anything with the map data we provided or have any other suggestions on how we can render the data for optimal performance.

Thanks,
Mike

[MichaelErlich]

Tested with using 'Reference all Data'.  On the toughbook described above, it didn't load the data at all.  Not sure what I am missing with the map pack.  The map pack worked fine on my workstation, but failed to load anything when all the data and reference pack were moved to the toughbook.  For my workstation, the load time went from 2min 10 sec to 5 seconds to load.  As I mentioned in a previous post, even after the first load, I could still see the space on my hard-drive drop on large packs.  So, it looks like there is something going on with the map data on subsequent loads.  Busy frames can still take a little why to load as it draw the entire extent before displaying.  This is less noticeable on panning since the original image stays and gets moved.  It gets noticed a lot more on large panning movements and zoom changes.  The less busy the frame, the quicker it draws.

[MichaelErlich]

We are seeing similar performance issues with the apk and gpk files on startup.  Any suggestions as to the best way to use these files to improve startup times similar to the mpk/tpk files?