Why would using the Smooth tool in ArcPro (2.3.0) take 54min versus 21 seconds in ArcMap (10.5.1)? I am running on the same machine, same inputs, same output location, and still is unusually slow. I have tried this on another machine with very similar

[PaulDudley]

[DanPatterson_Retired]

good case for Tech Support since you have documentation.

There is a lot of 'slow' talk as you probably know, but test cases are probably few. You should forward this on

[ThomasColson]

I suspect that this is related to BUG-000118472 Decrease in script performance in ArcGIS Pro compared to ArcMap when working with the arcpy.AddCodedValueToDomain_management geoprocessing tool, as, in general, most Pro GP tools function far slower than the same tool in ArcMap, with, as you mention, the same data and the same workstation. Kory Kramer‌ this is easily repro'ed, I can open a case on it, but curious if Drew Flater‌ is aware of the global performance issues with GP in general, and this use case can be attached to that bug?

[DrewFlater]

I don't believe this is at all related to BUG-000118472.

Smooth Line and some other cartographic generalization tools were recently enhanced with some additional options, I believe the performance bug may have been introduced at that time. Paul Dudley‌ can you contact tech support with this issue, or post that data in a zip file for us to troubleshoot? I also see that the layer names used as input in the two screenshots is different, perhaps these contour datasets are different with regard to level of detail or vertices? 

Thomas Colson‌ the team is NOT aware of any global performance issues with geoprocessing in Pro. We fix individual tools like this geonet post describes as the reports come up, and as our testing finds issues. I don't believe I have heard any other report that all tools are slower in Pro, it is usually quite the opposite.

[PaulDudley]

I replied to the GeoNet email so hopefully there wont be two responses...   Thanks Drew Flater‌

I have contacted ESRI Support and have an open ticket.  The layers on my screenshots had the same input “Training_Contours_2ft”.   I provided the data to the customer service rep and they are looking into it now.   I will also provide this information to the representative.  The data is just 4sq miles of contours generated from a mosaicked set of USGS 3DEP DEMs.    Thanks for the response(s).  

-Paul

[ThomasColson]

Same data copied to two different FGDB's. I keep a "firewall" so to speak, between ArcMap and Pro I/O. 

[ThomasColson]

ArcHydro GP tools are slower, but I understand that's not ESRI's problem, and emails to UT remain unanswered. In the following examples, every input is the same (one copy of the same data with the same number of vertices), same input/output parameters. This has been the case since I started using Pro. GP Tools are slower. If I need to get something done with a GP tool, I do it in ArcMap. Many are exactly the same (Arc and Pro). 

[curtvprice]

By "ArcHydro tools" if you mean Fill, FlowDirection, FlowAccumulation, these have been re-engineered to do tiled multiprocessing. This means these tools will run slower for small rasters and dramatically faster for large rasters. If you force the tools to run on a single process (using the processors environment settings) they will run faster on small data sets. Your other examples are pretty compelling!

[ThomasColson]

Interesting....I wrote a python script to prove my point on fil, fdr, and fac. Any link to documentation on the tiled multiprocessing? I do a lot of hydro stuff, so this is something I want to solve. 

[curtvprice]

Parallel processing with Spatial Analyst—Help | ArcGIS Desktop