Issue with snapping and performance speed

17331
34
01-06-2012 09:49 AM
AngelaHansen
New Contributor
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
Tags (2)
0 Kudos
34 Replies
JeffAzevedo
New Contributor
10.1 snapping is basically unusable 😞

*After doing a quick test exporting the same data from our SDE to Shapefiles, everything works fine?
0 Kudos
JeffAzevedo
New Contributor
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?
0 Kudos
JeffAzevedo
New Contributor
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.
0 Kudos
JeffAzevedo
New Contributor
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.
0 Kudos
RyanMacVeigh1
New Contributor
>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.
0 Kudos
by Anonymous User
Not applicable
The snapping cache itself is in memory. The slowest part of the process is getting the features from disk into it.
0 Kudos
StevenChamberlain
New Contributor
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...
0 Kudos
MelissaJohnson
Occasional Contributor II
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!
0 Kudos
Joeysmith
New Contributor
That fixes my snapping issue, most of the time..
0 Kudos
chelseasteed
New Contributor
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
0 Kudos