Return to Answer

Well, all things being equal, I would normally point out that your .NET dictionary is implemented as a tree, and if it were balanced, (otherwise the time complexity would be worse) the time complexity would be O(log n) while ESRI's FindField is internally implemented as a Hash table, and thus a time complexity of O(1) which is much better.

Of course I said all things being equal. And in this case, they are not, because you are using .NET an there is the issue of context switching and marshalling which is better explained as the first item of a previous related post that I did about ArcObjects performance.

My recommendation to you is to switch to .NET Hash tables instead of the Dictionaries.

OK, moving on.

To answer your second question, under non-managed conditions(i.e not Java or .NET) the answer is super simple, just compare pointers of objects! The unique-instancing model (per thread) of the factory pattern used by the GeoDatabase guarantees that the objects will be the same.

For .NET, its multi-generation memory model throws this technique out of the window - from the .NET side.

Nevertheless, for comparing pointer equality of most ArcObjects, you can use IClone's IsIdentical method which basically compares memory addresses in COM land.

So what is the solution for the FeatureClass case (that AFAIK, doesn't implement IClone). You have to take the long route :(

Use IDataset::name on the FC to get a fully qualified name, and then go to the parent Workspace and verify its connection properties to make sure the db is the same. Funny enough, this also covers an interesting Versioning case (Two FCs that are connected to the same DB, but are connected to different versions of the same FC).

Update: My original observation about .NET Dictionaries is incorrect. Apparently, they are implemented as hash tables as Scott points out :)

Well, all things being equal, I would normally point out that your .NET dictionary is implemented as a tree, and if it were balanced, (otherwise the time complexity would be worse) the time complexity would be O(log n) while ESRI's FindField is internally implemented as a Hash table, and thus a time complexity of O(1) which is much better.

Of course I said all things being equal. And in this case, they are not, because you are using .NET an there is the issue of context switching and marshalling which is better explained as the first item of a previous related post that I did about ArcObjects performance.

My recommendation to you is to switch to .NET Hash tables instead of the Dictionaries.

OK, moving on.

To answer your second question, under non-managed conditions(i.e not Java or .NET) the answer is super simple, just compare pointers of objects! The unique-instancing model (per thread) of the factory pattern used by the GeoDatabase guarantees that the objects will be the same.

For .NET, its multi-generation memory model throws this technique out of the window - from the .NET side.

Nevertheless, for comparing pointer equality of most ArcObjects, you can use IClone's IsIdentical method which basically compares memory addresses in COM land.

So what is the solution for the FeatureClass case (that AFAIK, doesn't implement IClone). You have to take the long route :(

Use IDataset::name on the FC to get a fully qualified name, and then go to the parent Workspace and verify its connection properties to make sure the db is the same. Funny enough, this also covers an interesting Versioning case (Two FCs that are connected to the same DB, but are connected to different versions of the same FC).

Update: My original observation about .NET Dictionaries is incorrect. Apparently, they are implemented as hash tables as Scott points out :)

Well, all things being equal, I would normally point out that your .NET dictionary is implemented as a tree, and if it were balanced, (otherwise the time complexity would be worse) the time complexity would be O(log n) while ESRI's FindField is internally implemented as a Hash table, and thus a time complexity of O(1) which is much better.

Of course I said all things being equal. And in this case, they are not, because you are using .NET an there is the issue of context switching and marshalling which is better explained as the first item of a previous related post that I did about ArcObjects performance.

My recommendation to you is to switch to .NET Hash tables instead of the Dictionaries.

OK, moving on.

To answer your second question, under non-managed conditions(i.e not Java or .NET) the answer is super simple, just compare pointers of objects! The unique-instancing model (per thread) of the factory pattern used by the GeoDatabase guarantees that the objects will be the same.

For .NET, its multi-generation memory model throws this technique out of the window - from the .NET side.

Nevertheless, for comparing pointer equality of most ArcObjects, you can use IClone's IsIdentical method which basically compares memory addresses in COM land.

So what is the solution for the FeatureClass case (that AFAIK, doesn't implement IClone). You have to take the long route :(

Use IDataset::name on the FC to get a fully qualified name, and then go to the parent Workspace and verify its connection properties to make sure the db is the same. Funny enough, this also covers an interesting Versioning case (Two FCs that are connected to the same DB, but are connected to different versions of the same FC).

Well, all things being equal, I would normally point out that your .NET dictionary is implemented as a tree, and if it were balanced, (otherwise the time complexity would be worse) the time complexity would be O(log n) while ESRI's FindField is internally implemented as a Hash table, and thus a time complexity of O(1) which is much better.

Of course I said all things being equal. And in this case, they are not, because you are using .NET an there is the issue of context switching and marshalling which is better explained as the first item of a previous related post that I did about ArcObjects performance.

My recommendation to you is to switch to .NET Hash tables instead of the Dictionaries.

OK, moving on.

To answer your second question, under non-managed conditions(i.e not Java or .NET) the answer is super simple, just compare pointers of objects! The unique-instancing model (per thread) of the factory pattern used by the GeoDatabase guarantees that the objects will be the same.

For .NET, its multi-generation memory model throws this technique out of the window - from the .NET side.

Nevertheless, for comparing pointer equality of most ArcObjects, you can use IClone's IsIdentical method which basically compares memory addresses in COM land.

So what is the solution for the FeatureClass case (that AFAIK, doesn't implement IClone). You have to take the long route :(

Use IDataset::name on the FC to get a fully qualified name, and then go to the parent Workspace and verify its connection properties to make sure the db is the same. Funny enough, this also covers an interesting Versioning case (Two FCs that are connected to the same DB, but are connected to different versions of the same FC).

Update: My original observation about .NET Dictionaries is incorrect. Apparently, they are implemented as hash tables as Scott points out :)

Well, all things being equal, I would normally point out that your .NET dictionary is implemented as a tree, and if it were balanced, (otherwise the time complexity would be worse) the time complexity would be O(log n) while ESRI's FindField is internally implemented as a Hash table, and thus a time complexity of O(1) which is much better.

Of course I said all things being equal. And in this case, they are not, because you are using .NET an there is the issue of context switching and marshalling which is better explained in a previous related post that I did about ArcObjects performance.

My recommendation to you is to switch to .NET Hash tables.

OK, moving on.

To answer your second question, under non-managed conditions(i.e not Java or .NET) the answer is super simple, just compare pointers of objects! The unique-instancing model (per thread) of the factory pattern used by the GeoDatabase guarantees that the objects will be the same.

For .NET, its multi-generation memory model throws this technique out of the window. For most objects, you can use IClone's IsIdentical method http://help.arcgis.com/en/sdk/10.0/arcobjects_net/componenthelp/index.html#//0042000000mv000000 which basically compares memory addresses in COM land.

So what is the solution?

Use IDataset::name on the FC to get a fully qualified name, and then go to the parent Workspace and verify its connection properties to make sure the db is the same (this also covers the versioning case)

Well, all things being equal, I would normally point out that your .NET dictionary is implemented as a tree, and if it were balanced, (otherwise the time complexity would be worse) the time complexity would be O(log n) while ESRI's FindField is internally implemented as a Hash table, and thus a time complexity of O(1) which is much better.

Of course I said all things being equal. And in this case, they are not, because you are using .NET an there is the issue of context switching and marshalling which is better explained as the first item of a previous related post that I did about ArcObjects performance.

My recommendation to you is to switch to .NET Hash tables instead of the Dictionaries.

OK, moving on.

To answer your second question, under non-managed conditions(i.e not Java or .NET) the answer is super simple, just compare pointers of objects! The unique-instancing model (per thread) of the factory pattern used by the GeoDatabase guarantees that the objects will be the same.

For .NET, its multi-generation memory model throws this technique out of the window - from the .NET side.

Nevertheless, for comparing pointer equality of most ArcObjects, you can use IClone's IsIdentical method which basically compares memory addresses in COM land.

So what is the solution for the FeatureClass case (that AFAIK, doesn't implement IClone). You have to take the long route :(

Use IDataset::name on the FC to get a fully qualified name, and then go to the parent Workspace and verify its connection properties to make sure the db is the same. Funny enough, this also covers an interesting Versioning case (Two FCs that are connected to the same DB, but are connected to different versions of the same FC).