15

Although I use python to create geoprocessing scripts/services, I was under the impression that using ArcObjects to do the equivalent operation(s) will have better performance.

I've posted ArcGIS Server GP Service - RasterIO.dll crashing ArcSOC.exe and ArcGIS Geoprocessing Script runs fine in Desktop but crashes as Geoprocessing Service? over the past couple of days about getting geoprocessing scripts that use Spatial Analyst tools to work as geoprocessing services. My deadline is fast approaching, so I have decided to go the SOE route to achieve the desired functionality.

Getting a cost path analysis in ArcObjects was relatively straight-forward using the .NET ESRI.ArcGIS.SpatialAnalyst.RasterDistanceOpClass, specifically the CostDistanceFull() and CostPath() Methods.

Some code snippets of how I am doing things:

Python

# Get Cost Path Origin and Destination Points
inputPointsShp = 'D:/RasterStuff/test_points.shp'
arcpy.MakeFeatureLayer_management(inputPointsShp,"origin",' "TYPE" = \'ORIGIN\' ')
arcpy.MakeFeatureLayer_management(inputPointsShp,"destination",' "TYPE" = \'DESTINATION\' ')

# Check out the ArcGIS Spatial Analyst extension license
arcpy.CheckOutExtension("Spatial")

# Execute CostDistance
outCostDistance = CostDistance("origin",SOURCE_RASTER,"#","backlink")

# Execute CostPath
outCostPath = CostPath("destination", outCostDistance,"backlink")

# Convert Result to Polyline
arcpy.RasterToPolyline_conversion(outCostPath, "leastCostPath")
featSet = arcpy.FeatureSet("leastCostPath")

C#

IDistanceOp distanceOp = new RasterDistanceOpClass();
IRasterBandCollection costDistanceRaster = (IRasterBandCollection)distanceOp.CostDistanceFull((IGeoDataset)sourceFc, (IGeoDataset)raster, true, true, false);
IRasterBand distanceRaster = costDistanceRaster.Item(0);
IRasterBand backLinkRaster = costDistanceRaster.Item(1);

IGeoDataset costPath = distanceOp.CostPath((IGeoDataset)destFc, (IGeoDataset)distanceRaster, (IGeoDataset)backLinkRaster, ESRI.ArcGIS.SpatialAnalyst.esriGeoAnalysisPathEnum.esriGeoAnalysisPathForEachCell);

A cost path analysis in ArcPy (using sa.CostDistance and sa.CostPath) takes approx 15-20 sec. Using the exact same inputs, the ArcObjects based routine takes 55-60 sec. Even using the .NET Geoprocessor is significantly slower than arcpy.

I guess my questions here are:

  1. Are the ArcPy and ArcObjects implementations pointing at the same code base (through their Python and .NET wrappers)?
  2. Any tips to optimize ArcObject based Cost Path analysis?

closed as too broad by PolyGeo May 11 '16 at 8:45

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    have you profiled your code to find iut exactly which call is taking the longest? Can you show a code snippet? – Ragi Yaser Burhum Jul 8 '12 at 0:46
  • My understanding was ArcPy just a wrapper around ArcObjects so that is curious. I dont know if this is relevant but one answer here : gis.stackexchange.com/questions/171304/… .. Notes that GeoProcessing tools need to load, as compared to GUI tools. So, if ArcPy instantiates the relevant code in advance or wraps a GUI function instead of the ToolBox function, it might skip some set up time. Easy enough to check by seeing if the speed gap reduces with larger datasets. – AnserGIS Mar 29 '16 at 9:32
  • As per the Tour there should be only one question asked per question. – PolyGeo May 11 '16 at 8:46
0

I believe that's because your Python is using ArcPy to call Geoprocessing tasks, which are running in 64-bit processes. ArcObjects happens in 32-bit processes.

  • 2
    There's not enough information in this post to make those assumptions. Even so, Server is 64bit or if he has 64bit BG installed he could execute his function tool against it. However, to entertain the thought, simply going from 32 to 64bit doesn't provide a performance increase. It's very situational when/if 64bit is 'faster' than 32bit. – KHibma May 4 '16 at 0:25
  • OP can clarify whether these assumptions are off base or not. The links I provided support the assumptions, like performance being better because there is access to more system resources, etc. There is a reason why most OS's are 64 bit these days, and one of the big ones is performance increases. So all things being equal, especially with heavy number crunching, 64 bit processes will out perform 32 bit processes. – alexGIS May 4 '16 at 15:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.