> Hi Craig, Peter

> Thank you for the inputs.

> Removing sorting helped quite a lot and I also reduced the result size
> from 100 to 10. Now the response times have come down to a few milliseconds
> but the downside is that the results are not sorted upon the distance.

> The objective is to get 10 places per page starting with the closest one.
> To implement this I tried following GeoPipeline functions

> 1. startNearestNeighborSearch(layer, point, distance) and
> 2, startNearestNeighborLatLonSearch(layer, point, distance)

> but none of them returned the results sorted on distance even if the
> function names seem to suggest so. As per the function definition, no
> additional sort filters are needed so please let me know if I am missing
> something.

> I also observed that the results of startNearestNeighborLatLonSearch are
> better sorted than startNearestNeighborSearch and think it has got
> something to do with the propertyFilter that these functions use. I would
> like to know more on  "OrthodromicDistance" and "Distance" properties and
> the difference between their respecitive property filters.

> Regards
> Abhijeet

> On Friday, 19 October 2012 19:04:56 UTC+5:30, Craig Taverner wrote:

>> I can suggest that since you have a sorting component in the pipeline,
>> this will cause the pipeline to internally cache the entire resultset on
>> the first hasNext or next call, sort it and return the first sorted result.
>> Subsequent calls will access the internal, sorted, cache. This is a
>> necessary consequence of the sorting algorithm, and is mostly unavoidable.

>> So avoid this, you would need to take away the sort. Is it possible to
>> get the same results you want without the sort? Or at least by moving the
>> sort into your own code, or perhaps after a filter or some other action
>> that reduces the resultset size?

>> On Fri, Oct 19, 2012 at 2:13 PM, Abhijeet Deshpande <avdes...@gmail.com>wrote:

>>> Hi Peter,
>>> Thank you for the response.

>>> Actually this is not related to the very first run of query where the
>>> cache is empty.

>>> The problem is that when ever I try to search places and request for 100
>>> places per page in response, first call to Pipeline.hasNext() /
>>> Pipeline.next() always takes about 400 sec. time and this happens for every
>>> request.

>>> Hope I am able to convey the problem that I am facing.

>>> Regards
>>> Abhijeet

>>> On Monday, 15 October 2012 18:35:04 UTC+5:30, Peter Neubauer wrote:

>>>> Hi there,
>>>> the first run is probably with cold caches. In real world scenarios,
>>>> you are running with warm caches, so you should try to warm up the
>>>> database by doing a few searches before the real work, or maybe loop
>>>> through your interesting nodes or so?

>>>> Cheers,

>>>> /peter neubauer

>>>> G:  neubauer.peter
>>>> S:  peter.neubauer
>>>> P:  +46 704 106975
>>>> L:   http://www.linkedin.com/in/**neubauer<http://www.linkedin.com/in/neubauer>
>>>> T:   @peterneubauer

>>>> Neo4j 1.8 GA - http://www.dzone.com/links/**
>>>> neo4j_18_release_fluent_graph_**literacy.html<http://www.dzone.com/links/neo4j_18_release_fluent_graph_literacy.html>

>>>> On Mon, Oct 15, 2012 at 2:10 PM, Abhijeet Deshpande
>>>> <avdes...@gmail.com> wrote:
>>>> > Hi
>>>> > I am using neo4j spatial to find out locations near by a lat/long.
>>>> The
>>>> > results returned are sorted on OrthodromicDistance and are further
>>>> paginated
>>>> > using the range function (100 results per page). The code for this is

>>>> > GeoPipeline flowList =
>>>> > (GeoPipeline)GeoPipeline.**startNearestNeighborLatLonSear**ch(layer,
>>>> loc,
>>>> > dist).sort("**OrthodromicDistance").**copyDatabaseRecordProperties(**keys). range(low,

>>>> > high);

>>>> > Now to iterate over this GeoPipline, I am using hasNext() / next()
>>>> functions
>>>> > but for some reason the first call for either of these functions
>>>> takes long
>>>> > time to execute.

>>>> > When the application was run, first call to next() or hasNext() took
>>>> > approximately 400 sec to execute, subsequent 99 calls took 0ms.

>>>> > Can someone please point out where the mistake is and if there is a
>>>> faster
>>>> > way to find the nearest places. The layer has 10 million entries.

>>>> > Regards
>>>> > Abhijeet

>>>> > --

>>>  --