Vishful thinking…

Bulk loading data into ESRI FeatureClasses

Posted in Uncategorized by viswaug on October 12, 2007

Yesterday, I was talking to a developer who was writing import scripts to load data from his legacy databases into ArcSDE FeatureClasses. Half way into our discussion, I realized that he wasn’t taking advantage of the IFeatureClassLoad interface in ArcObjects which speeds up the importing of data into the ArcSDE by magnitudes. It achieves it performance boost by suspending updates to the spatial index after every feature is added to FeatureClass and by updating the spatial index only after the FeatureClass is taken out of the load-only mode.

To quote ESRI’s documentation

IFeatureClassLoad is an optional interface supported by feature classes in ArcSDE and feature classes and tables in File Geodatabase. It improves performance of data loading.

With ArcSDE, putting a feature class in load-only mode disables updating of the spatial index while data is loading. In a File Geodatabase, putting a feature class or table in load-only mode disables updating of spatial and attribute indexes while data is loading. Taking the feature class or table out of load-only mode rebuilds the indexes.

While a feature class or table is in load-only mode, other applications cannot work with the data. A feature class or table should be placed in load-only mode only after acquiring an exclusive schema lock on the feature class via the ISchemaLock interface.

The dataset extent reported by the IGeoDataset::Extent property is recalculated when a feature class is removed from LoadOnlyMode to reflect the data present in the feature class.

Dig into this code sample here for more details on using IFeatureClassLoad. And if you end up locking up your FeatureClass while using IFeatureClassLoad, use the ‘sdetable‘ with the ‘-o normal_io‘ option to get yourself out of trouble.

Quick notes on Reflection performance in .NET

Posted in Uncategorized by viswaug on October 12, 2007

Here are some quick notes to keep in mind if you are using Reflection in your projects. You probably know that using Reflection takes a toll on the performance of your application. Bearing the following in mind when you are using Reflection in your projects can help you design better performing applications.

Fast and Light Functions

Costly Functions

  • typeof
  • Object.GetType
  • typeof == Object.GetType
  • Type equivalence APIs (including typehandle operator overloads)
  • get_Module
  • get_MemberType
  • Some of the IsXX predicate APIs New token/handle resolution APIs in the .NET Framework 2.0
  • GetXX APIs (MethodInfo, PropertyInfo, FieldInfo, and so on)
  • GetCustomAttributes
  • Type.InvokeMember
  • Invoke APIs (MethodInfo.Invoke, FieldInfo.GetValue, and so on)
  • get_Name (Name property)
  • Activator.CreateInstance


 This figure illustrates the invocation mechanisms and their performance overheads.


Type.InvokeMember is the slowest of the late-bound invocation mechanisms because there are two functions that InvokeMember needs to perform to properly invoke a member. First, it must figure out the exact member it’s supposed to invoke, as determined by the user’s string input, and then perform checks to be sure the invocation is safe.

MethodBase.Invoke, on the other hand, doesn’t need to figure out which method it must call because the MethodBase already holds the identity of the method.