Best Practices for Optimal Performance in ArcFM - Customizations

Version 4

    Many customizations slow performance. Autoupdaters impact editing performance, and display namers slow map rendering. When determining whether or not to implement a customization, consider the performance impact as well.

     

     

    Autoupdaters

     

    Autoupdaters that run inefficient queries are one of the biggest detriments to performance. If you suspect your custom autoupdaters may be slowing performance, enable Schneider Electric's Application Metrics (available on versions 10.2.1 and later) and share your hash code with Technical Support. More information about Application Metrics is available here: https://infrastructurecommunity.schneider-electric.com/docs/DOC-3024.

     

    Map Refreshes

     

    Customizations that frequently refresh the map will also slow performance. Schneider Electric recently made changes to the ArcFM product to avoid full refreshes of the map during editing and experienced a performance increase. If you implement a customization that refreshes the map, the following simple changes to your customizations should improve performance by decreasing the number of map refreshes.

    IActiveView.PartialRefresh

    If you call IActiveView.PartialRefresh to refresh a single draw phase (e.g., graphics layer or geography layer), follow it with a call to IScreenDisplay.UpdateWindow. Here's a VBA snippet to illustrate:

     

    'refresh only the graphics phase

     

    Call mxDoc.ActiveView.PartialRefresh(esriViewGeography, Nothing, Nothing)

      mxDoc.ActiveView.ScreenDisplay.UpdateWindow

     

    Refresh commands accumulate until the window has an opportunity to process them. Sometimes this results in unexpected interactions which impact performance, as in the following example:

     

    'this causes a full screen refresh

     

    Call mxDoc.ActiveView.PartialRefresh(esriViewGraphics, Nothing, Nothing)

      Call invalidArea.Invalidate(esriScreenCache.esriAllScreenCaches)

     

    The intermediate UpdateWindow flushes any prior requests, thus preventing the interaction between PartialRefresh and Invalidate which would have resulted in a full extent refresh of all screen caches:

     

    'this avoids the full refresh:

     

    Call mxDoc.ActiveView.PartialRefresh(esriViewGeography, Nothing, Nothing)

     

    mxDoc.ActiveView.ScreenDisplay.UpdateWindow

      Call invalidArea.Invalidate(esriScreenCache.esriAllScreenCaches)

     

    IInvalidArea.Invalidate

    Any place you call IInvalidArea.Invalidate to refresh a local area (e.g., the envelope around a feature whose attributes were just updated), pass in a specific screen cache ID. You can obtain the cache ID for a specific draw phase (or all draw phases) of the map with the IActiveView.ScreenCacheId property:

     

    The InvalidArea object is usually prepared like this:

     

    Dim invalidArea As IInvalidArea

     

    Set invalidArea = New invalidArea

     

    Set invalidArea.Display = mxDoc.ActiveView.ScreenDisplay

      Call invalidArea.Add(someFeature)

     

    Then you are ready to invalidate the rectangle defined by your feature's shape. Most code samples show it this way:

    Call invalidArea.Invalidate(esriScreenCache.esriAllScreenCaches)

     

    But this method is risky because any other pending map refreshes get combined with this one and they interact. So instead of invalidating all screen caches, get a specific cache ID and invalidate only that one cache. Here's an example to draw all phases:

     

    cacheID = mxDoc.ActiveView.ScreenCacheID(esriViewAll, Nothing)

      Call invalidArea.Invalidate(cacheID)

     

    Here's an example to draw only the geography phase:

     

    cacheID = mxDoc.ActiveView.ScreenCacheID(esriViewGeography, Nothing)

      Call invalidArea.Invalidate(cacheID)

     

    Both of these examples refresh only the requested envelope rather than the full extent.