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

[Oyvind Idland]

Hello Dan and Greg,

we are currently using 3.5, and we are in the middle of a release. I could
patch 3.5 locally and use
our own binaries.

I'll try to run the test suite during beginning of the week, and check if
the tests triggers new code. I assume
there are tests that validates geometries. I can add necessary test code if
I find that something is left out.

After testing I can attach the patch.

PS the memory leak I mentioned was fixed in a different way than I
described.


-- Oyvind




On Fri, Feb 18, 2011 at 5:23 PM, Dan Stoica <dan.stoica at autodesk.com> wrote:

>  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>
> 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
>
>
>
> _______________________________________________
> fdo-users mailing list
> fdo-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-users/attachments/20110219/f8d42a2a/attachment.html