If you’ve ever put together a stored display, you’re likely aware of the effort that it can take to make things perfect.

You have a wealth of settings to get that map document to look and function exactly as necessary, and it can normally take a fair amount of time to get this done.

But after all of your data is present and things look just perfect, there’s a chance that it can still run slowly. What gives?

Esri and Schneider Electric, over the years, have provided a lot of solutions for optimizing the performance of stored displays.

A lot of these suggestions are meant for the geodatabase, while some of them are ways in which you can reduce the load on the stored displays themselves (for example, avoiding blank symbology in favor of definition queries). Many of Esri’s suggestions are published here.

Today, though, we are highlighting a method that can help a lot, but requires a bit of custom code: the ArcFM™ Cache Login Object.

Logging into ArcFM™ requires selecting a database connection, at which point the stored items and various other settings are loaded into the application and made available.

An ArcFM™ Login Object is a customization that allows users to augment or replace the standard ArcFM™ Login screen with custom functionality.

After it is built in code an deployed, it is set with a registry key:
The premise of the Cache Login Object is simple. Once the user logs in, the login object has a working connection to the geodatabase. It then uses this connection to retrieve all feature classes and standalone tables in the geodatabase, and it actually loads each one into memory.

The relevant classes and tables are retrieved from a custom view, as well, which allows them to be used efficiently in code and filtered out if desired. When the tables have all been loaded, each one gets cached for later use to increase performance at the cost of some extra time at the start of your ArcMap session to cache the tables.

So, how does this help performance? In an average environment, there are many references to other items (such as standalone tables and related feature classes) that aren’t explicitly included as a layer or table in the stored display.

These references can be contained in the stored display layer settings, in custom code, or elsewhere. Without this login object, if the tables were referencing are not directly in the stored display, they have to be loaded specifically when they’re needed and aren’t loaded until that point.

That can often produce longer load times in the middle of certain operations, in addition to general performance slowdowns as this happens. Because of that, the more work that a user needs to perform, the more beneficial this login object will be for them.

We traced the performance of the login object recently in a SQL Server Profiler trace. While the cached login object performed a significant amount of queries during login, it resulted in fewer queries against the GDB_ITEMS and SDE_COLUMN_REGISTRY tables, and faster performance overall.

The rate of GDB_ITEMS queries was reduced by 72% in the cached session, and the rate of SDE_COLUMN_REGISTRY queries was reduced by 22%.

Notably, this functionality is different than Esri’s feature cache. It works similarly in concept, but deals with classes instead of individual objects.

This particular login object was originally created by Esri as a login object with a custom GUI that replaces the standard ArcFM™ Login screen, but SSP has implemented variations where nothing looks different and the out-of-the-box login functionality still works (the extra logic will simply happen after login).

Since only one login object can be implemented at a time, systems with an existing login object would need to integrate this functionality into what already exists.

This is not a “sample code” post, as the functionality is a little deep to share here, and it often can end up being slightly tailored to each system. But if you have any interest in having an ArcFM™ Login Object created for you or developing one yourself, this login object may be able to help.

We’ve seen good results with the implementations of this concept so far, so we think it’s a worthwhile effort if you need to get every bit of performance out of your stored displays.