More and more the web mapping developers at AGRC have been avoiding the use of ESRI WebADF controls for performance reasons, flexibility, and the bugs we have found in them. We have adopted ArcObjects as are tool of choice when dealing with ESRI spatial data. Currently we are planning to upgrade our web service architecture and algorithms, so I explored 3 different geocoding methods to find out which was the quickest.

The three methods that were explored were

•  A composite locator file. This .loc file contains references to 4 geolocators that reside in SDE.  This way you can get the best matches by combining all 4 locators.  To use this in a web service environment I had to add the .loc file to a file based geodatabase and use arc objects to invoke the query.
• Direct connecting to SDE with ArcObjects, opening the 4 locators in code, and writing my own logic to choose the best address match.
• Publishing 4 Geocode Services in ArcGIS Server, consuming them through WebADF code, and writing my own logic to choose the best address match.
  

The first thing I did was a cost/benefit analysis to figure out what the benefits of each geocoding method would be. This was only something I did in my head and nothing fancy.

• Composite
  
  • The composite locator means I don't need to write any of my own logic.
  • I don't have to publish any services in ArcGIS Server which consume a connection to SDE.
  • I can rely on ESRI's algorithm to be optimized and produce the best results.
  • I lose the flexibility to manage which address is returned.
    
    

• ArcObjects
  
  • I have to write all my own logic. More time spent but more flexibility.
  • I don't have to publish any services in ArcGIS Server whichconsume a connection to SDE.
     

• WebADF
  
  • I thought this would be slow.
  • I have to publish services in server which make our DB Admin get angry since we max out the number of connections alloted for SDE.  ESRI please make a distinction between application and direct connects already!
  • I get to write my own logic which means I spend more time but I gain flexibility.

I ran a quite test for a single address and this was my result. Note that GeocodeZip3 is using ported 9.2 code with some deprecated calls to initialize the resources.  This

ArcObjects took 4.078125 seconds
Composite  took 12.15625 seconds
WebADF took 11.59375 seconds

My conclusions from this are that ArcObjects are fast.  The composite probably isn't returning from geocoding when it gets a highly scored match and that is why it is so much longer (Always geocoding with 4 locators).   Finally, the web ADF is just slow.

Today I came in and revamped the WebADF code.  I didn't spend any time with it since I am a little biased thinking they would be slower. Turns out I was really really really wrong. The WebADF code through ArcGIS Server Geocoding Services is reeeeeeeeeeealy fast. The graph below shows the average time in seconds for each method to return a correct result.  The test involved 4 addresses that would get the best match with each of the 4 locators.

My conclusion from these findings is that since the Geocoding Services spools an arcSOC.exe process when you start them (or they should you can set them to 0 if you wanted) that the time spent initializing the resource is not there.  I think the main factor slowing the other two methods down is connecting to SDE at runtime.