merlich

Performance with Large Map Sets

Discussion created by merlich on Aug 30, 2011
Latest reply on Sep 8, 2011 by merlich
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

Outcomes