Improve performance on GetGeometry

[maland]

We have done some profiling of the GetGeometry function in the ArcSDE provider. The performance when reading large geometries is rather poor. In one of our datasets we have rather large MultiLineString geometries, eg. one geometry consisting of 35581 lines (71260 points). For this particular geometry, the GetGeometry function takes 4-5 seconds to execute! The profiling reveals where the vast majority of the time is spent:

83 % : SE_shape_get_num_points
 9 % : FdoArrayHelper

I have attached a profiling screenshot for reference.

The SDE API offers a SE_shape_as_WKB functions which runs in just 2-3 milliseconds. Could that be used in conjunction with a Wkb2Fgf? That would greatly improve speed for large multi-geometries.

Regards Henning Maland

[maland]

GetGeometry profiling screenshot

[oyvndi]

The main perfomance killer turned out to be SDE's API, such as SE_shape_get_num_points().

I removed all the existing buffer handling, including code inside macros (which makes debugging impossible). Instead I added the DynamicBuffer-class, which is a simple class that handles allocation, using templates.

I also did related code cleanup, and the amount of code in total is now slightly reduced.

[oyvndi]

(Attached new files that didn't svn diff doesn't include)

[gregboone]

The current plan is to commit these changes into the Trunk. There is no current plan to backport these changes to 3.6.

[jng]

Fixed r6245