Slow editing in 10.1

[RobbHodges]

I've been having issues when editing a version 10 geodatabase in ArcGIS 10.1 from the network. Editing a version 9.3 seems to be fine. With ArcGIS 10, I was having zero issues editing from the network. Basically, selecting anything has a noticeable delay. Moving anything results in at least a 10 second delay. Editing the same data on my local results in zero problems.

I called tech support and they initially blamed it on the network. Well, 2 days prior, it worked fine on the same network. There were no changes made to the network, only to the upgrade of version 10 to 10.1. We then tried renaming the normal.mxt and the esri folders in the registry. That didn't work either.

Has anyone experienced this in 10.1? It's a bit frustrating, because we really need this to work from the network. I am editing on my local right now as a temp fix, but eventually that won't work.

Thanks,
Robb

[aaronhill]

Zone 111-
Renaming the ESRI folder didn't work for me? Any other processes have you tried?

[HusseinNasser]

Just to confirm that we have the same issue, Slow editing + arcmap crashes frequently with errors

Problem signature:
  Problem Event Name: APPCRASH
  Application Name: ArcMap.exe
  Application Version: 10.1.1.3143
  Application Timestamp: 5058f74e
  Fault Module Name: StackHash_4183
  Fault Module Version: 6.1.7601.17514
  Fault Module Timestamp: 4ce7ba58
  Exception Code: c0000374
  Exception Offset: 000ce653
  OS Version: 6.1.7601.2.1.0.18.10
  Locale ID: 1033
  Additional Information 1: 4183
  Additional Information 2: 418393d3a499c8ae8ed0a6df247c128b
  Additional Information 3: c8cd
  Additional Information 4: c8cd612dd071564a925536fa3384b159

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt

 

or sometimes this error

Description:
  Stopped working

Problem signature:
  Problem Event Name: APPCRASH
  Application Name: ArcMap.exe
  Application Version: 10.1.1.3143
  Application Timestamp: 5058f74e
  Fault Module Name: mscorwks.dll
  Fault Module Version: 2.0.50727.5420
  Fault Module Timestamp: 4ca2b820
  Exception Code: c0000005
  Exception Offset: 00163298
  OS Version: 6.1.7601.2.1.0.18.10
  Locale ID: 1033

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt

I understand this is a .net error as we have some custom applications on top of ArcMap written on .NET but still those applications were working just fine on 10.0 for more than 2 years.

Client ArcGIS 10.1 SP1, geodatabase 10.0

Any thoughts would be helpful!

Thanks!

[AndrewBrown1]

Has ESRI contacted anybody on this thread regarding their slow editing experience? I hate to begin any ESRI bashing here, but the "slow editing" has been around since 9.3.1. Previously, I thought it was due to editing features within shapefiles on a file system, but now I'm editing features that are stored in our SDE instance and the editing experience is still dreadfully slow. So slow, in fact, that my snapping tool doesn't even work. The only way to get around it, that I found thus far, is to open a new session and only drag in the layers that require editing, as well as a reference layer.

Pretty pathetic considering that this performance problem has been around for a while.

And no, it's not my network or server that is the problem.

[KennethFoltz]

I had significant problems with editing in 10.1. So much so that I was forced to go back to 10. It would initially run fine and then just start to crawl. I do not have this issue with 10, however. There is another tech in the office on 10.1 that doesn't experience any difficulties at all. None of the suggestions from ESRI (deleting .mxd, removing toolbars, etc.) helped any so for now, 10 it is.

[Joeysmith]

The manhole featureclass is fine when editing locally.

[ScottMoucka1]

I occasionally have the same issue as Chad75 and there doesn�??t seem to be any rhyme or reason to when it occurs.

A map document will work just fine until I begin an editing session. As soon as I move the �??cross-hairs�?? into the map extent I get the Windows 7 blue circle indicating the computer is thinking. When this behavior begins Arc won�??t snap for the rest of the day. Doesn�??t matter which mxd I open, old or new, how many layers I have in the TOC or where the layers reside, server or local machine�?�behavior doesn�??t return to normal until I return to the office the next day after shutting down my computer for the night. A restart does not fix the issue. Outrageously frustrating!

Why hasn�??t an ESRI representative responded to this thread?

[RobertoGallone]

Enabling snapping (classic snapping)
http://resources.arcgis.com/en/help/main/10.1/index.html#//01m60000000z000000

[MarkBoucher]

I just noticed the slowness when editing one layer with a 2' contour polyline layer on. When I turn it off the contour layer, the problem goes away. Certainly the snapping is "looking" around and has a lot to consider. Reducing the number of layers (features) that are turned on seems to help.

[TimBarnes]

Yep- It's slow for me as well. It doesn't seem to be network related par se as drawing speed is good (i.e. aerial photography and vector features) but selecting a feature results in a good 5 second delay, beginning editing is around 10 seconds- This is with all snapping turned off.

What I have noticed is that you have features in your map from a slower network location, even if they aren't turned on/visible, performance will be a lot slower- My working document is a mixture of local data, data from a networked machine in the same office and data from a networked machine in an office a long way away- After removing that data from the other office, selection speed and editing speed increased dramatically.

[MichelleBoivin]

We are going through this exact same scenario here. ESRI just came in and reworked WATER's old database model and set up 6new datasets, including two new geometric networks for water and sewer. We are on SDE 10.1 SP1, SLQ 2008R2 and everything has begun to chug.

What we tried:
1) Turned off hyper-threading which made a noticeable difference to our users
2) Had them enable Classic snapping when editing, which helped
3) Enabled feature caching, which is actually suggested by ESRI when working with geometric networks (see article http://resources.arcgis.com/en/help/main/10.1/index.html#/Performance_considerations/002r00000004000...) - this helped but is at a user level and we have over 300 users

What we tested:
1) Tested the drawing of all layers and performance of the processors on the server when using the networks (SLOW!), then turned those layers off and amazingly enough, things were better.
2) Also took a look at the Performance Monitor on the server and it appears that all of the hits were to the temp locations. If you read the article from above, you will notice ESRI says that a geometric network is now "executing a separate spatial query on the server for each feature class in the network. If coincidence is discovered, then network connectivity is established. The cost of maintaining the connectivity on the fly is execution of these queries, which can be expensive."

We have also checked the network (no issues), maxed database connections to over 64 (we were reaching 61 consecutive connections), and then all the basic info mentioned (normal.mxts, ESRI folders, etc.)

I believe this to be a performance "enhancement" on ESRI's part (sarcasm slightly intended) and they appear to admit that there is a large overhead now for geometric networks.

As for a resolution I am not sure. My thoughts at this time for us are to have a snapshot that is updated programatically on a regular basis for our general users (readers) so they aren't panning and "querying" everytime they try to locate a water main....but that's a business practice call....

I am glad to have found this post as I have been searching everywhere for information, so as I find out more information on our end I will post for everyone else.

I should also mention that our geometric network was created as a 10.1 network and was not migrated from a 9.3 network.