Iteraor in FeatureResult is too slow

Description

Calling method iterator() or features() on FeatureResult takes long time (about 8 seconds if I have lots of objects) while simle query take about 1 second. Interface of FeatureResult should be chaged to improve performance. (i.e get(index) methods. Instead of HashMap there should be used object for faster access.

Environment

None

Activity

Show:
codehaus
April 10, 2015, 3:19 PM

CodeHaus Comment From: jgarnett - Time: Thu, 22 Jul 2004 10:53:45 -0500
---------------------
I don't know where to start - can you give us any clue which datastore is too slow? This is really a datastore specific problem.

We cannot provide a get( index ) method - the data returned by a datastore is not ordered. This reason also prevents us adding a skip method to FeatureReader.

That said here is a topic on Random Data Access.

<a href="http://docs.codehaus.org/display/GEOTOOLS/Random%2BData%2BAccess">http://docs.codehaus.org/display/GEOTOOLS/Random%2BData%2BAccess</a>

There is no HashMap for FeatureResults; FeatureResults is better named PrecannedQuery - while a DataStore implementation could grab a ResultsSet and quickly iterate over it to my knowledge none of them do. They all make a new query each and every time you call reader().

So yes this should be faster:

1) Implement a FeatureResults that works ontop of a JDBC Result set.

2) Implement some of the ideas from <a href="http://docs.codehaus.org/display/GEOTOOLS/Random%2BData%2BAccess">http://docs.codehaus.org/display/GEOTOOLS/Random%2BData%2BAccess</a>

codehaus
April 10, 2015, 3:19 PM

CodeHaus Comment From: jgarnett - Time: Mon, 4 Oct 2004 16:34:45 -0500
---------------------
Optimize! Or cache? Only you can decide

codehaus
April 10, 2015, 3:19 PM

CodeHaus Comment From: dzwiers - Time: Thu, 21 Oct 2004 14:37:15 -0500
---------------------
DataStore not specified.

Assignee

Unassigned

Reporter

codehaus

Triage

None

Fix versions

Affects versions

Priority

Highest
Configure