Where's the Performance?

09-24-2018 01:31 PM
Regular Contributor II
3 1 1,029

Just for grins, I thought I would compare performance across the newer SDKs (Pro, Enterprise, and Runtime) to see how they compare to ArcObjects and arcpy.  As a benchmark, I chose a purely computational task: generate 100,000 random convex hulls (initialization times are excluded).  For Desktop environments, the results are as follows:


SDK Execution Time (seconds)

Pro SDK529
arcpy (Desktop 32-bit)*516
arcpy (Pro 64-bit)164
Runtime .NET16

*Running as a tool in a Python toolbox; running at the Python prompt takes 635 seconds!


Reworking the results into a performance index is telling:



As you can see, Runtime .NET is the grand champion performer.  ArcObjects/C++ is roughly a third as fast.  And even though it's somewhat faster than ArcObjects/.NET, Pro SDK still drags its feet at 9% the speed of ArcObjects/C++, and 3% the speed of Runtime .NET.

On the server side, the results are as follows:


SDK Execution Time (seconds)

arcpy (as a GP service)419
ArcObjects/.NET SOE160
Enterprise SDK SOE147
ArcObjects/C++ SOE10


And as a performance index:



Enterprise SDK is again slightly faster than ArcObjects/.NET, but only has 7% the speed of ArcObjects/C++.  So why do the Pro and Enterprise SDKs perform so poorly?  Looking under the hood reveals some clues.  On the Pro side, the giveaway is the [STAThread] attribute:



This indicates that the Pro SDK uses COM interop, just like ArcObjects .NET.  Debugging the Enterprise SDK benchmark also reveals the presence of COM:



In other words, the Pro and Enterprise SDKs are nothing more than lipstick on the same old COM interop pig as ArcObjects/.NET.  Runtime aside, you're far better off sticking to ArcObjects/C++ if you really want the best overall performance. [COM interop performance is even worse in Java!]


1 Comment