[postgis-devel] Lame attempt at cascade union in sql
Martin Davis
mbdavis at refractions.net
Fri Aug 8 09:39:08 PDT 2008
Point taken, Mateusz.
Perhaps what I should have said was: "GEOS union *as it is currently
implemented* is probably 2-3 times slower than JTS - and I think that
this is related to memory allocation performance".
Mateusz Loskot wrote:
> Martin Davis wrote:
>> Java is much more efficient at memory allocation than C++ is (at
>> least, using std C++ memory operations). So barring a stroke of
>> genius in GEOS-land I think JTS is alway going to out-perform.
>
> A bit OT, but I can and can not agree.
> GC allocation implements more sophisticated allocation strategies and
> is typically faster than manually new'ed/malloc'ed storage in C/C++.
>
> But allocating everything in dynamic storage on the heap, costs a lot.
> In C++, programmer can and should follow the rule of "no allocation
> costs nothing" and prefer stack wherever possible.
> In GEOS, I've found it as a major problem. GEOS mimics Java approach
> almost directly without incorporating C++ patterns and optimizations.
>
> Next issue is that standard containers in C++ use standard allocators
> that solve most common cases and guarantee robustness on all platforms.
> For special conditions, it's highly recommended to invent dedicated
> allocators and use them with standard containers.
> Custom allocators in C++ are likely out-perform Java allocators + its
> cost of garbage collector.
>
> p.s. I hope I've hit principles of substantive discussion and you
> won't get my post as a holly war. Flame is not my intention.
>
>
> Best regards,
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
More information about the postgis-devel
mailing list