[geos-devel] JTS/GEOS performance

[Martin Davis]

Poor alloc performance would be my first guess for the performance
difference.  I would think Java is pretty optimized for memory
allocation, since it relies on it so heavily.  

I think one standard approach to handling slow malloc is to build a
sub-allocation layer.  This would be made a bit easier in GEOS, since
almost the allocation done inside geometry methods is released at the
end of the method.  You could probably even dispense with the free calls
as long as you were operating in the memory pool.  (One messiness that
would need to be thought out is how to support exposing the various
components such as tree indexes and noding while still allowing a custom
allocator to be supplied.  Or you could just forget about this and just
support access through geometry methods.  This is getting pretty far
from the philosophy of JTS though...).

I'm not enough of a C expert to know if this is the best route to pursue
- anyone have any other ideas?

Martin Davis, Senior Technical Architect
Vivid Solutions Inc.      www.vividsolutions.com
Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046


> -----Original Message-----
> From: strk at refractions.net [mailto:strk at refractions.net] 
> Sent: January 28, 2005 4:20 AM
> To: geos-devel at geos.refractions.net
> Subject: [geos-devel] JTS/GEOS performance
> 
> 
> Some time ago I've been researching about GEOS performance 
> problems as related to JTS. Attached is a shapefile and an 
> .xml test you can use to compare the two.
> 
> JTS does not support buffers tests, so you'll need to use 
> another method for that. I used JUMP, which reports computation time.
> 
> Well. The operation is a buffer(polygon, 2000).
> 
>  JTS:  18 seconds
> GEOS: 574 seconds (9 minutes, 34 secs)
> 
> GEOS computation keeps the CPU pretty busy (98.2-99.8%)
> and takes up to about 170 MB of ram
> 
> JTS seems to use 3 threads, the bigger using at most 80% 
> of CPU, but most of the time far below that point.
> JUMP reports 104MB committed, but I'm not sure about the meaning.
> 
> For GEOS, valgrind reports (with buffer 500):
>  malloc/free: 2982697 allocs, 2982697 frees, 924407212 bytes 
> allocated.
> 
> How much do you think this wild allocation negatively 
> influence the poor performance of GEOS ?
> 
> --strk;
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net 
> http://geos.refractions.net/mailman/listinfo/geos-devel
>