Vishful thinking…

ArcObject, PostGIS and spatial operations performance

Posted in GIS by viswaug on December 19, 2008


I have caught myself cursing at ArcObjects numerous times for not being performant for some of the spatial operations I had done using it in the past. I have also heard the same about it from other developers I have come across in the past. But what I was always curious about was, how does ArcObjects compare in performance to the other open-source spatial libraries like PostGIS? Since I have always been swimming in the ESRI and .NET ocean, I have little or no knowledge on how the PostGIS and Java worlds performed. So, it was interesting to listen to John Coryat speak this thoughts on how using the PostGIS library (that sits on top of the PostgreSQL database) makes spatial operations up to 10 -100 times slower than if those operations where performed using the spatial operations built into Postgresql.

Both ArcObjects and PostGIS suffer from the same drawback that make them significantly slower, they both are spatial libraries that run outside of the process space of the database where the spatial data is stored. Please see comments from Paul Ramsey below explaining that PostGIS actually runs within the process space of the database and how recents changes have made it considerably faster. ArcObjects runs outside of the process space of the database where the spatial data is stored.And that takes a major toll on the performance. Most databases these days including MS SQL Server 2008 pack a powerful set of spatial operations built right now that can satisfy the requirements for some cases but definitely not all of them. The spatial operations that are built right into the databases should always be prefered over using external spatial libraries since they run magnitudes faster. But the problem is that spatial operations included in those databases are not comprehensive and they all don’t pack the same geometry operations either. Most of them do support the SQL functions outlined by the OGC like SQL Server 2008 but some don’t. The most notable memberwould be MySQL.

To overcome or to add more capability to the spatial operations in these databases, an external spatial library become a necessity. Expecting the database vendors to develop spatial operations and to have to them keep up with the developments in the industry would not be an attractive option. This puts us, the spatial developers, in a catch-22 situation wherein we need to give up on performance to gain more powerful spatial capabilities. So, we may not be able to FIX the performance issues with spatial operations but just patch it as needed.

Even though John Coryat talks about his experience with PostGIS and PostgreSQL performance comparisions, that still doesn’t give a comparision between ArcObjects and PostGIS performance. It would be interesting to see some performance benchmarks between the two though.


ArcGIS Server – Now faster and prettier in 9.3.1?

Posted in ArcGIS, ESRI by viswaug on December 19, 2008

I have to say that I am intrigued by this announcement about improvements in 9.3.1

What’s Coming in ArcGIS 9.3.1?

Especially the coming improvements in the dynamic map publishing below and also the Map Server Document (MSD) format.

High-Performance Dynamic Map Publishing

  • New faster rendering engine
    • Outperforms equivalent ArcIMS services.
    • Produces significantly better-looking maps.
    • Shortens map caching time.
    • Quicker, smoother zoom and pan.
  • New Map Optimization toolbar in ArcMap helps you tune-up your map documents before publishing to ArcGIS Server.
  • Review and respond to errors, unsupported content, and warnings about items that will slow down your dynamic map services.
  • Preview your optimized map document and estimated rendering time.
  • Save your optimized map document to the new Map Server Document (MSD) format.