As unintuitive as it seems, I�??ve discovered that defragging a hard drive can adversely tweak the performance of a file geodatabase. After deleting and recopying my test dataset, I�??m getting numbers that once more are in line with what I�??ve seen in the past. Here are the revised stats, and I�??ve added a few extra languages for comparison:
9.3.1 scores (seconds):
C++/ATL: 13
VBA: 14
Python/comtypes: 40
Python/arcgisscripting: 43
VB .NET: 47
IronPython: 54
Java: 81
C#: 1235
F#: 1235
C++/CLI (unmanaged): 1561
Beta 2 scores (seconds):
C++/ATL: 7
VBA: 8
Python/comtypes: 33
VB .NET: 43
IronPython: 43
Java: 77
Python/arcpy: 111
C#: 1202
F#: 1204
C++/CLI (unmanaged): 1536
C# is the real shocker: all along I�??ve assumed that C# has about the same performance as VB .NET. Boy, was I wrong.
I�??ve also been looking at F#, which is supposed to be ideally suited for asynchronous parallel processing. Sounds great for geoprocessing, doesn�??t it? Not if you�??re using ArcObjects: its performance is about the same as C#.
At the bottom of the dung heap is C++/CLI. 😛 I was enthusiastic about it for a brief time last year, because you could have both managed and unmanaged code in the same project. Sounds like the best of both worlds, right? Yeah, until you look at the performance. Good bye.
The walk-away lesson here is: avoid using fine-grained ArcObjects in anything but C++ (not CLI!!) or VBA. Instead, create coarse-grained objects in C++ and then consume them in other languages. See y'all at the Developer Summit!
😉
