[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