Select to view content in your preferred language

Why is Network Analyst so pathetically slow in ArcGIS Pro?

2480
8
09-15-2017 11:01 AM
DougKampe
Regular Contributor

I do a lot of route and VRP analyses in ArcMap, which includes about 2500 bus trips and 20000 bus stops. Additionally, I have a very complicated bus tiering model that stacks bus trips efficiently. I have no problems completing these using ArcMap 10.4.1. However, I want to fully move to ArcGIS Pro (EDIT: I'm at 2.0.1), but when it comes to using Network Analyst Pro is terribly slow and unstable. It's basically unusable in it's current form. Here's a quick comparison. I just made 976 routes from 20282 bus stops. ArcMap, from loading stop points to completion is about 5 minutes. Pro takes about 3 minutes 21 seconds to load the stops and then it endlessly runs while drawing the routes. If I cancel there are, in fact, routes, but it's so slow (30+ minutes) just to get to that point I question if it can actually do the job. Finally, the bus tiering model I have works in Pro, but the VRP is so slow I have to use ArcMap. Pro will churn for hours, while the analysis is done in about 20 minutes in ArcMap.

Am I the only one experiencing this and if so is anyone at ESRI looking into resolving this?

Thanks,

Doug

Tags (3)
0 Kudos
8 Replies
MelindaMorang
Esri Regular Contributor

We made some changes in Pro 2.0 that significantly speed up the Solve operation.  Please let us know how the performance compares after you upgrade to 2.0.

0 Kudos
DougKampe
Regular Contributor

I'm sorry, I forgot I recently upgraded and I am at Pro 2.0.1, so to answer your question the upgrade hasn't helped speed-wise. I cannot speak of stability, but it hasn't crashed recently. 

0 Kudos
MelindaMorang
Esri Regular Contributor

Would you be willing to share a project package with us so we can try to figure out what's causing the slowness?  Please include your network dataset and the layer(s) you're solving.

0 Kudos
DougKampe
Regular Contributor

Yes. Who or where should I post the package? 

0 Kudos
MelindaMorang
Esri Regular Contributor

I sent you a private message.  Not sure if you saw it.

0 Kudos
DougKampe
Regular Contributor

I did. I will get the data to you tomorrow.

Thanks,

Doug

Get Outlook for Android<https://aka.ms/ghei36>

0 Kudos
MarcoBoeringa
MVP Regular Contributor

One thing that strikes me in your post is the

"Pro takes about 3 minutes 21 seconds to load the stops and then it endlessly runs while drawing the routes."

remark.

I have no solution for you, but I have had some bad experience with Pro and tools or custom models that interact with the TOC (e.g. adding layers) that require re-drawing. As Pro always seems to trigger immediate re-drawing whenever something changes in the TOC, and the re-drawing seems to heavily influence a currently running tool in some cases, I have seen some tools almost grind to a halt... Unfortunately, it seems that Pro's geoprocessing tools are not completely separated from the drawing engine, despite the app being multi-threaded.

While I can to some extent understand that Pro triggers immediate re-drawing with any change in the TOC, in my opinion this should never hold up geoprocessing tools, and any subsequent changes to the TOC (addition of a new layer) should ideally immediately stop execution of any running drawing process, so as to avoid any long delays caused by unfinished drawing processes. This is especially so, since any subsequent change to the TOC, of course invalidates any currently running drawing process. If a layer is added or deleted from the TOC, the drawn map frame needs an entire refresh, so it would be best to immediately halt execution of any draw process going on.

I even see Pro trigger "re-drawing" with the spinning wheel, when the entire map frame of a layout is set invisible by unchecking it in the TOC. This holds up execution of tools for seconds without a clear reason: why would it need to re-draw the layout when there are no visible features at all?

DanPatterson_Retired
MVP Emeritus

If it is redraw related... check your cache... and/or set your cache properties for any layers you don't want to redraw

I am assuming you have a more that beefy video setup to begin with? 

And the ultimate test would be to script the workflow and run it outside of an open ArcGIS pro session to see if it is indeed slow by virtue of being open.