[fdo-users] Re: SDE and slow multi-geometries

[Greg Boone]

Can you create an svn patch and attach it to the ticket related to this defect? Once that is done I can have a few people look at the changes and have it submitted.

At this point these changes can go into the trunk, and possibly the 3.6 branch. Is there a requirement to have the changes ported back to 3.5?

Greg

From: fdo-users-bounces at lists.osgeo.org [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Oyvind Idland
Sent: Friday, February 18, 2011 5:05 AM
To: FDO Users Mail List
Subject: [fdo-users] Re: SDE and slow multi-geometries

The code is now fixed. As I got started, I also did some related code cleanup:

- the macro function EXPAND() are now gone. Instead, I made a simple templated
array class with an array subscript operator. This looks much cleaner now and can be
debugged.


- the macro function ADD_POINT is also gone, replaced with an inline static function.


- memory leak: ArcSDEConnection, line 885:

CHAR *qualified_table_name = new CHAR[SE_QUALIFIED_TABLE_NAME+1];

This one never gets deleted. I can't see any reason to use new, so I replaced it
with an array instead:

CHAR qualified_table_name [SE_QUALIFIED_TABLE_NAME+1];



However, there are still things I'd like to do with the code: The geometry buffering is
attached to the ArcSDEConnection class, and functions like convert_sde_shape_to_fgf()
are poking around in these arrays (XY, Z, parts etc). What I would like to do, is to
wrap all these arrays together with the indexing code into a new SDE geometry
handling class. This won't add anything new, just make it more clean.


Where can I submit/send the changes ?


-- Oyvind


On Wed, Feb 16, 2011 at 4:53 PM, Oyvind Idland <oyvind.idland at gmail.com<mailto:oyvind.idland at gmail.com>> wrote:
Hello,

I have been looking into an issue that was brought up here earlier. Turns out that the SDE API
is slower than cold molassis when using SE_shape_get_num_points() on multipart geometries.

I did some experimentation using the index tables returned from SE_shape_get_all_points()
directly. The total processing speed on my dataset went from roughly 20 secs down to less than
1 sec. There are several huge polygons with 200+ holes in them, and multilines.

Why the native SDE API is so slow is a mystery, those indices should not require heavy
calculation.

The code is experimental so far, but when I finish writing the code, I can submit a patch
if desired.


-- Øyvind Idland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-users/attachments/20110218/2e0bb180/attachment.html