[fdo-users] Re: SDE and slow multi-geometries
Dan Stoica
dan.stoica at autodesk.com
Fri Feb 18 11:23:10 EST 2011
Hi Oyvind,
In addition, before submitting the patch please run the unit tests suite.
Does your change needs a specific unit test thus making sure it is exercised?
Dan.
From: fdo-users-bounces at lists.osgeo.org [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, February 18, 2011 10:19 AM
To: FDO Users Mail List
Subject: RE: [fdo-users] Re: SDE and slow multi-geometries
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/b9e3f6d5/attachment-0001.html
More information about the fdo-users
mailing list