Very cool - comments inline. On Wed, Sep 9, 2009 at 6:32 PM, Andrea Aime<aa...@opengeo.org> wrote: > I did some more testing and it seems to be a matter of queue depth: > - with a queue depth of 100 it may get to be 10% slower in some cases > - with a queue depth of 1000 (which matches the fetch size we use > by default with the database) it may be 5% slower in some cases > - with a queue depth of 10000 it's always as fast or faster
Okay this matches the experience of queue size with the WFS DataStore. The larger the queue the more work that can be done without blocking etc... For WFS we settled on a queue length of 100 but that was for a very slow parse process. > Same goes with shapefile backend, with higher queue depth I get > higher performance. However, 10k might also mean using a lot > of memory to keep in memory all those features. > It's probably a good idea to make prefetching and queue size > a user configurable thing. I like it - provide a hint for queue size; and if it is 0 no queue will be used. > Maybe the best approach is to create a prefetching wrapper > at the feature source level, which would return prefetching > collections and thus prefetching iterators (in fact only > the iterator would be prefetching, everything else would be > there to inject prefetching at the map context construction > level). All the best, Jody ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
