ArcMAP 10.5 Slow Performance

[TerryAdams]

Hello All,

We have just updated from ArcGIS 10.3 to ArcGIS 10.5.

Suffering from very slow performance in ArcMAP now with certain things.  I've completely re-made MXD's from scratch under 10.5 that I had under 10.3 to remove possible changeover issues.

When I simply tick on/off layers it takes a long time (1 minute or more) to update the display or give me control of ArcMap back.

When I save edits - long time to do that (2 minutes or more) 

When I change a layer from editable to not editable - long time (1 minute) to do that.

I'd have maybe 10 layers in the MXD with JPEG 2000 aerial photo loaded in - but not displayed. 

Arc Catalog displays layers quickly - as you'd expect.   Loading one or 2 layers into ArcMAP also seems ok.  But more than that *really* seems to slow it down.  I never had extremely slow responses like this under 10.3.

We're putting in a support call but just wondering if anyone else has noticed this - and might know what the cause is.   Data sits in SQL 2012 with ARCSDE.   

[TerryAdams]

Some findings.  This is at the limit of my knowledge so I will describe it as best I can.

ESRI Australia have identified what looks like a bug with ArcGIS 10.5 and SQL 2012.

The issue is around the indexing of nvarchar (max) fields in SQL.  So - fields that are set with nvarchar (max) in SQL are causing problems in ArcGIS - because ArcGIS can't index them properly...... resulting in very poor performance.

If in SQL you change the nvarchar(max) definition to nvarchar(254) - the issues disappear.

The way we tested things was choosing a feature class with say 10,000 records in Arc Catalog and try and sort on any of the fields.  If you have nvarchar(max) set in SQL - this took a *very* long time.  Set to nvarchar(254)  and the sorting was back to around 10-15 seconds as usual.

After we have made the changes in SQL to all our datasets (a days work) - I will report back if the poor performance issues have indeed disappeared.  Initial testing though seems promising. 

Hope that makes sense.  The nitty gritty of databases isn't my forte. 

[DanPatterson_Retired]

Terry, if it works out, could you edit your original discussion title to indicate it is with SQL. It would make it easier to identify the source route of the problem for people searching on a similar issue.

[TerryAdams]

Yes ok Dan I will do that once we have properly verified the outcome.    

[KoryKramer]

Terry,

Wondering if you made any progress on this...?

[TerryAdams]

The issues are still *not* fully resolved unfortunately no.

The issues I spoke about with SQL above *were* having an impact in certain situations - and with certain operations - but it does not appear to be the full picture.   Fixing the nvarchar(max) instances in SQL - as well as completely reworking all the indexes - has *not* fully solved the sluggish ArcMAP performance.  We ended up getting a SQL tech in to go through our SQL setup with a fine tooth comb.  He found a few minor things - but nothing that has made the ArcMAP issue go away.  We've seen a minor improvement it must be said.   So...  although all of that has helped - the sluggish ArcMAP issue remains.

We really see it when switching layers on and off, zooming in and out,  and when we put scale dependencies on labels etc etc.  Also when saving edits, this really takes a long time now.

We then hit upon building feature caches in ArcMap to aid with zooming in and out - which also *does* help with reducing draw times when working in ArcMAP.  So that helps.  But switching the layers on & off still takes ages.

We really see a difference now with scale dependencies - where features or labels switch off at certain scales etc.  This seems to make things very slow.  Much more so than previously.

We did also hit upon a suspicion that datasets switched over to high precision under 10.3 weren't so happy in 10.5.  No real concrete evidence for this but nevertheless we re-did this under 10.5 to tick that box.

We also made sure our SQL box wasn't maxing memory and killing the machine's performance or anything like that.

So - we feel we've chipped away at the problem as much as we can - and improved things a small amount - but we feel now the remaining issue is a bug with ArcMAP.  Arc Catalog seems completely fine and responsive like you'd expect.

We did have an issue sometimes with Arc Catalog where it would go crazy - creating 10 tabs in the windows task bar and flickering our screens like mad.  Fixing the nvarchar issue, the indexes, and the high precision issue (only suspected)  and making Arc Catalog happy seems to have stopped this from happening.  That first appeared under 10.3 and originally didn't seem to have any effect beyond the flickering screen for a few minutes.  We suspect now it was probably due to issues we had with our setup at 10.3 - but which really didn't affect things then.  At 10.5 those issues *did* come home to roost. 

So - no silver bullet I'm afraid.  But hopefully that helps somewhat.

[KoryKramer]

Thank you for following up with all of the details, Terry.  That is definitely very helpful.  Did you do all of that troubleshooting in conjunction with Technical Support?  Was there a Support Case open for this issue?  I'm asking because there is a bug that *might* be causing what you're experiencing, but the issue should first be vetted with support: BUG-000097186: Data displays slower in ArcGIS 10.4 for Desktop.. 

While that bug is still showing as New to the public, I can say that it is actively being worked on and hopefully there will be a fix soon.  You might want to subscribe to it to get updates.

Also, have you looked at this thread: Slow - 10.4 Client with Sql Spatial Views 

Hope the above is of use.

[JustinConnerWR]

Did the change in ArcGIS in Desktop 10.4 for views persist into Pro  https://community.esri.com/thread/216224-fundamental-flaw-when-opening-attribute-tables-in-arcgis-pr... 

[MichaelVolz]

Have you ever tried to copy all the layers in a troublesome mxd that are stored in the SQL 2012 database to a file geodatabase where you completely re-create the mxd sourcing the layers from the file geodatabase and never switching the data source from the original SQL 2012 database connections?  I am recommending this course of action so the mxd in 10.5 has no reference whatsoever to the SQL 2012 database.  I've had ghost connections to SDE databases in the past that could only be removed by recreating mxds.

Did you ever look at this thread for ideas to solve (minimize) this problem:

https://community.esri.com/thread/175596 

[MinottKerr]

We are seeing as similar slowness issue with migrating from mxd's created in desktop 10.1 to version 10.4/10.4.1/10.5 and connecting to a SQL Server 2012 Enterprise Geodatabase version 10.4.

The result of our tech support case was the creation of the bug report: #BUG-000102726 (ExecuteSpatialQuery performs slower for SQL Server feature classes beginning at ArcGIS 10.4).

The issue isn't solely around a spatial query but as well simply trying to draw a large number of features at small scale which had not been an issue at desktop 10.1 connecting to the 10.4 version Enterprise Geodatabase. 

[TerryAdams]

Apologies for the late reply.

Yes we've done much of the troubleshooting in whilst in contact with technical support, and we most certainly have a case logged with them.  They have actually been very good with getting onto the situation, albeit without result.

Kory:  Thanks for those links and the heads up.  I will keep an eye on those situations as well.  It's very possible they could well be linked with what we're experiencing. 

For a particular MXD - if we copy all the feature classes it uses from SDE into a locally stored file geodatabase - then yes the slowness *does* go away.  So far as we've tested anyhow.   But we have a number of officers editing versioned feature classes so that gets a little frustrating / time consuming to manage.

Minott:  Our issues do sound very similar to yours.  We are also of the opinion now there's a bug / issue somewhere with 10.5 over 10.3 (that we moved up from).

Our support case is still being nutted through - we know of at least one other similar issue in Australia.  But nothing new I'm sorry to say.