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

[JeffAzevedo]

10.1 snapping is basically unusable 😞

*After doing a quick test exporting the same data from our SDE to Shapefiles, everything works fine?

[JeffAzevedo]

I talked to tech support and they had me make a new mxd and import my layerfiles from my old (10 or 9.3.1) mxd into the new 10.1 mxd. This fixed all of my snapping problems.

Also, they made me aware of a current 10.1 bug that changes your map's coordinate system after you add in certain basemaps (mine was when I added in Bing Aerial basemap). so check your maps coordinate system and make sure it is the same as your data. This will cause your snapping to be slow or unusable also.

Thanks for the reply.

We don't have any older files to use, so I saved a blank MXD (10.1) and added the same features back in (ArcSDE 10.1) and it worked fine, until I added another feature. So the original test of Subdivisions & Centerline features now snap very well, but when I added our streets, it's back to poor performance. Very strange.

Any chance you are using MSSQL 2008 with the Spatial Data types?

[JeffAzevedo]

I think it has something to do with SDE's and not the vertices count, because I can export the Streets feature to Shapefile, and it works perfectly.

[JeffAzevedo]

This might help others using MSSQL 2008.

(Our problems revolved around very slow snapping, measure tool and any queries)

The SQL Spatial types have impaired our performance greatly. When running the same problematic features as SDEBinary, in the same Dataset, our performance issues are gone. Is this a fix for all using MSSQL 2008? I can't say that for sure, but it definitely has made a big difference on our data.

If you are running a similar setup. Simply copy and paste a feature into the same Dataset, and change the keyword to SDEBinary. If you don't see SDEBinary, you may be setup where the Binary option is your default. You could check DBTune to see the default "GEOMETRY_STORAGE", ours is set to "GEOMETRY".

Good luck.

[RyanMacVeigh1]

>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.

Is the snapping cache cache in memory or on disk? If it�??s on disk what is its location? We have a client with a very restrictive environment and they are experiencing the same issues as others here. I think it could be caused by insufficient privileges to the directory of the snapping cache.

[Anonymous User]

The snapping cache itself is in memory. The slowest part of the process is getting the features from disk into it.

[StevenChamberlain]

I think it has something to do with SDE's and not the vertices count, because I can export the Streets feature to Shapefile, and it works perfectly.

I had a similar issue as other users in this thread, and in working through it noticed that if the layer I'm editing is in a different workspace than the one I wanted to snap to (2 FCs in 2 separate File GDBs...), it seemed to work much faster...so I wonder if its not so much an issue of format (i.e. SDE vs. Shapefile), but instead an issue of the editable workspace...

Just wanted to add my $.02 in hopes it may help...

[MelissaJohnson]

I have horrible trouble with snapping being slow and jerky.  I am cutting polygon features.  This is with both classic and new snapping and have adjusted the snapping tolerance.  One other thing I have noticed is that the Control - V to show vertices also is flaky.  You sometimes have to hold the button down for a long time or try several times to get the vertices to show up, and even then they don't always all appear.  It is really annoying.  Sounds like there are a lot of folks having issues with it.  Hope it get fixed in the next service pack!

[Joeysmith]

That fixes my snapping issue, most of the time..

[chelseasteed]

I was having the same problem with snapping and editing slowing to a crawl.  I remembered having an issue with trace a while back and a previous forum workaround/suggestion was to fix the spatial index which in that case had become corrupted for some reason. So I decided to check the properties of the feature I was trying to snap to in ArcCatalog and saw there was no spatial index. Remedied that and now snapping is fully operational again. Not sure why the spatial index sometimes becomes corrupted (I'm not tech savvy) and new to Arcmap but it was a simple fix that worked for me. Hope this helps