Issue with snapping and performance speed

[AngelaHansen]

Hi All,

We have been encountering problems lately while editing (using 10 sp 2). The speed of ArcMap while editing slows to a crawl, and snapping will not work (unless classic snapping is enabled).

I was wondering if anyone else has encountered this issue?

Thanks,
Angela

[RhondaGlennon]

Do you have a basemap layer (created either by Add Data > Add Basemap Layer or New Basemap Layer in the table of contents) in your map? We have found that sometimes large features in basemaps can cause snapping performance issues. If so, try turning off the basemap and seeing if snapping improves.

Please contact Esri Support so an analyst can work with your data and help us resolve issues like this.

[RichardFairhurst]

Hi All,

We have been encountering problems lately while editing (using 10 sp 2). The speed of ArcMap while editing slows to a crawl, and snapping will not work (unless classic snapping is enabled).

I was wondering if anyone else has encountered this issue?

Thanks,
Angela

This is always a problem in all version of 10 I have used (SP3 currently) and I find it virtually unusable.  If the spatial index of a layer is not operating correctly it make editing nearly impossible.  Since we went from Oracle to SQL Server our parcel layer's spatial index does not work correctly which makes editing nearly impossible if the new snapping environment is on, since that layer is our biggest.  But the same problem occurs if there are a large number of layers in the map.  The more layers and the larger number of features in the layers has a huge effect on snapping performance with the new snapping environment.  I have not tried experimenting with adjusting snapping tolerances, but that would be one place to start.  Other than that contact Tech Support as suggested above.

[TylerBoyle]

I also had this issue while editing. Make sure all of the data in your map is in the same projection. ArcMap will warn you which layers have a different projection than the data frame when you start editing. After I did this my editing jumped to near instant speed and snapping worked like a charm.'


Hope this helps,

Tyler

[MikeMacRae]

I've had the same performance issue too. Usually only with large file size datasets. I've had issues with snapping. The only work around I've found was to start a new ArcMap, ad the editing layer as the only layer and edit from there. That fixes my snapping issue, most of the time, my performance issue. This may not be workable for you though. ESRI, please fix!

[KalvanHone]

I am experiencing similar performance issues with snapping in ArcGIS 10 SP4.

I've been searching for information on how the snapping environment works as it appears to require caching of all potential snapping geometry into memory when starting an edit session, but this thread is the only information I've found talking about performance issues.

My observations are similar.  The fewer layers in the map document, the better editing/snapping experience.  The smaller the files, the better the snapping experience.  Switching to the classic snapping environment provides no boost in performance.  I didn't test snapping using files in different projections/coordinate systems, but I think the comment regarding indexing is right on.

The biggest breakthrough came when I loaded only two layers in ArcMap and tested snapping to a 150Mb parcel shapefile and ArcMap fell on it's face and was excruciatingly slow with no snapping ability.  Snapping on the same parcel file loaded into file geodatabase...very fast with no problems.  Snapping performance on the same parcels loaded into SDE is somewhere in between.  I can open a map document with several SDE layers (including parcels), start an edit session, and although ArcMap performance does not slow down noticeably, the interactive snapping does not appear regardless of which features over which I hover!  I then walk away from my computer for 15 minutes, come back, and the interactive snapping magically starts working beautifully.

Please do not point us to help documentation on how to use snapping or another blog on how to effectively use the simple, flexible, and great new snapping environment.  Someone please provide better detail on what ArcMap does to enable snapping when an edit session is started please so we can find work-arounds to these snapping performance issues.

Thanks.

[Anonymous User]

As a generalization, snapping works by loading features into a snapping cache which is then evaluated against the cursor position. If you have a feature that has a lot of vertices such as the US coastline, a county boundary or the void between tax parcels (if you model this) then it takes time to load the entire feature into the cache. This is the largest performance bottleneck in the process.
Classic snapping and the new snapping work the same way, the difference being that you specify the layers in classic.

In addition to the basemap options for snapping in 10.1 we have also changed the feature loading algorithm, such that its faster than classic snapping for the same layers.

[KalvanHone]

Thanks for your response Sean.  This confirms my suspicion of a snapping cache for which I could find no documentation.  Can you please provide more detail on the feature loading algorithm?
For example:
Is this performance bottleneck related to issue NIM069319 fixed with SP3?
At what point is the feature loading algorithm called/started?
Does the feature loading algorithm load features into the snapping cache for the entire layer, or just what is inside the visible extent, or some combination thereof?
Does the feature loading algorithm load features into the snapping cache for only the layers visible in the table of contents, or visible and non-visible alike, or those layers in the editable workspace, or some combination thereof?
Does the feature loading algorithm take advantage of field indexing?
Would it make sense for the user to have some control over certain options in the Editor Options dialog on how the feature loading algorithm behaves?

Thanks again.

[Anonymous User]

>Is this performance bottleneck related to issue NIM069319 fixed with SP3?
No, that was a separate issue. The recent performance change was made to 10.1 only.

>At what point is the feature loading algorithm called/started?
Snapping is evaluated every time you move the mouse with a tool that has snapping enabled. This includes most of the editor tools and some outside such as the measure tool. Features are loaded as needed by the snapping environment. There's a bit more info in the developer help.

>Does the feature loading algorithm load features into the snapping cache for only the layers visible in the table of contents, or visible and non-visible alike, or those layers in the editable workspace, or some combination thereof?
All visible layers in the TOC that make sense (eg. not raster, annotation etc) are snapping candidates. Since its layer based it will also respect definition queries, scale thresholds etc.

>Does the feature loading algorithm load features into the snapping cache for the entire layer, or just what is inside the visible extent, or some combination thereof?
Features near the mouse location are loaded. Keep in mind a feature can extend way off the visible extent and this is one of the performance hits that we improved. Large complex features are the main problem here.

>Does the feature loading algorithm take advantage of field indexing?
It takes advantage of the spatial index and the arcmap feature cache if they are present. Performance improvements will vary here.

[KalvanHone]

Thanks again for your reply Sean.  The link you provided to the SDK documentation answers my remaining questions.