On 28/03/2010, at 8:30 PM, Andrea Aime wrote:

> Hi,
> took some time to look into vector data in memory
> caching to try and provide some response to those
> users that still find the rendering demos too slow.
> 
> First I've tried out the gt-caching module, with mixed
> success. Even allowing the StreamingFeatureCache to
> fully cache in memory the data the performance compared
> to a local shapefile does not improve, it's actually
> more or less the same.
> When allowing the cache to just keep in memory half of the
> features the performance drops very significantly,
> putting the cache at 1/3 of the performance of the
> shapefile data store when showing all of the data,
> and almost the same when very zoomed in.
> Anyways, this has not been bad, found a couple of bugs
> I could provide fixes for:
> http://jira.codehaus.org/browse/GEOT-3012
> http://jira.codehaus.org/browse/GEOT-3013
> 
> I've then looked into my old "cache everything in
> a spatial index" approach, getting more or less the
> same performance as the shapefile data store.

There is a post on gvSig mobile about just drawing from the spatial index (I 
assume at higher scales only):
- 
http://gvsigmobileonopenmoko.wordpress.com/2010/02/27/large-shapefiles-on-small-screens-using-a-drawable-spatial-index/

> After a bit o profiling found that the DefaultFeatureCollection
> was the cause of such disappointing results and
> rolled my own, making the attached caching feature
> source almost twice as fast as the shapefile
> data store.
> 
> It's still a toy, but for people that have small amounts
> of data can be an answer.
> Micheal, I don't feel like putting it in the official
> gt2 modules, but I think it would make a nice addition
> to the example one as a simple way to cache vector data?
> Maybe someone could pick it up and improve it.
> 
> Ah, finally, I've looked into the caching module and I have
> the impression it's possible to create a more compact (in terms
> of code), faster, self adapting cache (as in, the current one
> requires the user to hand tune the grid size to work properly).
> If anyone is interested I have put down on paper some
> design ideas

I think I better be interested; running some uDig 1.2 benchmarks against uDig 
1.1.1 was not pretty; going to try again formally
and make a bug report :-P

Jody


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to