ArcMap Feature Caching Strategies

In an enterprise environment ArcGIS is implemented in a client-server environment.  The database instance is on the server and the application (ArcMap) is on the client.  And even when there’s an application server in place that’s on a machine sitting physically adjacent to the database server in the company data center, you’re displaying map data feature geometries must be fetched from the database and rendered on the client.

Map display performance can be broken down into those two parts:  fetching and rendering.  The “fetching” part can be relatively expensive.  That’s why Esri added the ability to “cache” data in the client’s RAM to avoid having to go back to the database for repeated display of data in the same area.  The set of functions to create and manage caching is available on the standard ArcMap “Feature Cache” toolbar and documented here.

And it works, too.  In a recent informal example we tested display of a SDE feature class at its full extent, then built a feature cache at the full extent and repeated the display.  Using the Performance QA tool for timing we found that without the cache the display took 30.61 seconds and with the cache present the display took 14.4 seconds.  Not bad.

It’s All in How You Use It

However, the value of the feature cache depends on how it’s used.   It can be a really good friend if you apply it judiciously – but it can also be worthless, or worse, if you don’t.   Here, for example, are some Don’ts:

• Don’t try to create a feature cache of the full database.  That is when you’re zoomed to the full database extent with all layers displayed.   Ok, we’ll admit it.  This is what we tried the first time we got hold of the thing.    Why not?  We’re thinking – why have to go back to the database at all?  We’ll just put the full contents in private working memory and leave the database in the dust. 

  Of course if your Geodatabase is of any size, all feature geometries won’t fit within the 3GB of memory available to a single process under 32bit Windows. As you approach this limit ArcMap might realize its running out of space and just stop building the cache – so you’ll have wasted time trying to build the cache and have nothing to show.  You might also receive an “Out of Server Memory” error message.   Same effect.

• Don’t use the auto-caching option. You can set an option to automatically create a cache when you cross a designated scale threshold. This is our opinion, but we just haven’t seen it work consistently to the positive. The thing about caching is that it’s a trade-off. Creating the cache is not instantaneous. If it takes more time to create the cache than the time you’ll save using the cache then you’re in the negative. In normal panning and zooming around a utility Geodatabase the chance that you’ll benefit by a cache created each time you zoom in past, say 1:2,400… well again, we haven’t seen it.
• Don’t bother in a single user environment.   While display performance after building the cache is better than before building the cache, it doesn’t make up for the time it takes to create the cache in the first place.

However, just because you have think a little before you use caching doesn’t mean it’s not really valuable.   We try thinking before acting sometimes ourselves… it’s helped.

Here are some Do’s:

• Use it when you’re staying a while. If you know you’re going to operating, i.e., editing or querying features, in a concentrated area for more than just a few operations. Zooming in and out within a confined area – that’s the caching sweet spot.
• Use it in a large, sparse area. The time to create the cache and the cache size is not dependent on the current map scale – it is dependent on the number of features actually displayed in the map.
• Use it a multi-user environment. The value in having an in-memory cache really stands out when your otherwise contending with other users for access to the database. Having your own cache removes the competition.

Here’s are some examples:

Single User SQL*Server Geodatabase, Starting Extent 1:24,000

In this case we used the Performance QA Analyzer to compare display performance of zooming to 20 random extents within a 1:24,000 display area before and after creating a cache.  You can see that the 31.4 seconds it took after building the cache was certainly better than the 40.9 seconds it took before, when we include the 29 seconds it took to build the cache… no real overall value.

Single User File Geodatabase, Starting Extent 1:100,000

Now, display performance with a single user File Geodatabase is usually pretty good anyway.  And as we can see from the table below, again the time to build the cache may not make it worthwhile.

Multi User Oracle Geodatabase, Starting Extent 1:25,000

With multiple users simultaneously querying for features in the same database we can see where building a cache can really add value.  In the case below we saved over a minute simply in our display times.

Summary

Our course there are other variables that impact actual performance, not the least of which is the speed of your RAM which can influence the time it takes to build the cache.  (Note that our last test was performed with a client that had faster RAM than the first two tests.)

Nonetheless, when applied with a little forethought ArcMap Feature Caching can hopefully speed up some of the detailed operations you perform on your ArcGIS Geodatabase.