Where's the Performance?
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)
| ArcObjects/.NET | 577 |
| Pro SDK | 529 |
| arcpy (Desktop 32-bit)* | 516 |
| arcpy (Pro 64-bit) | 164 |
| ArcObjects/C++ | 47 |
| Runtime .NET | 16 |
*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 SOE | 160 |
| Enterprise SDK SOE | 147 |
| ArcObjects/C++ SOE | 10 |
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!]