Low Performance

[SvenJunghans]

Hi,

I really like this addin. But I find the performance very low sometimes, especially when I map all countries of the world: I have 1 row per country (a bit more than 200) and 2 columns (country name and a numerical value). I can barely pan or zoom.

I'm trying to find the bottleneck that's causing this low performance. I checked RAM, CPU and network speed, all seem fine.

I am using:
- Esri Maps for Office 2.1 for 32-bit
- Excel2010
- Windows7 32-bit.

Help is much appreciated.

[hanjun1]

As you mentioned you just can not pan or zoom the map, which should be not cause the performance issue.
I guess if there are some other process affect your action. You can just try with only one address and see what happen.
And what about your PC Hardware, I mean the Office2010 sometimes take much cosume for the RAM.

I used the api on my office2010 without any performance issue, my desktop also use Win7 + Office2010.

[SvenJunghans]

Thanks for the response,

Here are my PC hardware details:
RAM - 4GB (3.5GB usable due to 32-bit Windows7)
Processor - Intel Core 2 Duo CPU E8500 @ 3.16GHZ

Graphics Card is not as good as RAM and CPU. But I don't think that matters for Esri Maps for Office.

That's my office PC.
I tried Esri Maps for Office on my private home PC (gaming) which obviously has much better GPU, CPU is similar but has 4cores instead of 2, RAM is same. OS is Windows7 64bit, but office is 32bit (so I can only use the 32bit Esri Maps for Office Addin). On this PC I have the same issues.

Conclusion
In my opinion the cause of low performance - when mapping all countries of the world - could be 32bit Excel instead of 64bit.
Now if the country polygons (operational layers) are loaded on a server from Esri and not on the local PC, then it could also be "slow" connection/processing power of the Esri server? Perhaps because I'm using the trial version of ArcGIS Online my tasks have a "low" priority on Esri's servers.

Has anybody made similar experiences with low performance and 32-bit Excel or the trial?

My company is seriously considering getting ArcGIS Online - especially because of this addin. But the low performance issue is a huge con.

[hanjun1]

Thanks for the response,


Conclusion
In my opinion the cause of low performance - when mapping all countries of the world - could be 32bit Excel instead of 64bit.
Now if the country polygons (operational layers) are loaded on a server from Esri and not on the local PC, then it could also be "slow" connection/processing power of the Esri server? Perhaps because I'm using the trial version of ArcGIS Online my tasks have a "low" priority on Esri's servers.

Has anybody made similar experiences with low performance and 32-bit Excel or the trial?

My company is seriously considering getting ArcGIS Online - especially because of this addin. But the low performance issue is a huge con.

Or you can try some other Type "Address Data" ? like City or some other Point type(not polygons) and to see if the issue still occurs. I think the Esri server do the goecode with your "Data" and then send back as the Point or Polygon display on the map.
What about the performance about ArcGIS Online on your side?

[SvenJunghans]

I mapped some points. The performance starts to become critical at about 20,000 points (similar to the number of polygon vertices when mapping world countries?)
In ArcGIS Online the performance is significantly better. The operational layer may take a few seconds to load, but navigating (pan, zoom) is never really slow.

[JeffGarland_AGOL]

I'll chime in with a similar observation.  I think one has to make the distinction between geometry types and also the complexity of the feature (e.g. number of vertices).   I ran into this problem when using a custom location type where parcels where the location feature.  Things worked relatively well until we went from a couple of hundred to a couple of thousand.  In short, the map becomes unusable. All of this was done 32 bit Excel 2010 with the ESRI map add-in version 2.1.0.143 and hardware acceleration enabled.

I then tried an custom location type using PLSS sections (used the BLMs unique ID).  Still polygons but much simpler.  I could get up to about 5,000 and it start puking.  I could still filter for a smaller subset (a couple of hundred) and then performance would improve.  TO determine if it was somehow the server providing the custom location type, I create a spreadsheet of all the zip codes in the US (approximately 33,000 plus) and ran against the ESRI provided zip code location type.   If I started with a filtered data set and the result set being below a thousand things worked fine.  Once I started filtering to anything above 2,000 performance took a hit.  (Interestingly, the locator would return errors on the zip codes.  I downloaded the data from the census.  Not sure it they have erroneous zip codes or if ESRI locator is incomplete.)  Once I got to the point where there were too many records I couldn't recover.  I could remove the table from the TOC, filter to a smaller number, add the table back to the map, but it was locked up.

In summary, the add-in works great on points, but breaks down pretty quickly when you work with polygons.  I suppose you could write an Excel macro limiting the number of records that can be filtered and displayed in Excel, but that seems a bit convoluted.  Too bad, I really like the concept and the folks at my company love being able to visualize their data on the fly. Migrating to 64 bit Excel isn't a solution, because just about every other add-in in the world ( and we utilize quite a few) are still in the 32 bit world.

[ScottBall]

Hi folks -

Thanks for all the feedback throughout this thread. These comments have kicked off internal discussions about prioritization of future development work for Maps for Office. We are hearing that the performance of polygon-based layers needs to be improved and we will be working on that. We don't have any specifics to announce right now, but we are listening and your comments are directly helping to make the product better.

Thanks again,
Scott