> On Tuesday, 23 October 2012 01:11:02 UTC+5:30, Abhijeet Deshpande wrote:
> 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
> 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.
> 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
>>> Hope I am able to convey the problem that I am facing.
>>> 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?
>>>> /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/**
>>>> 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.
>>>> > results returned are sorted on OrthodromicDistance and are further
>>>> > using the range function (100 results per page). The code for this is
>>>> > GeoPipeline flowList =
>>>> > (GeoPipeline)GeoPipeline.**startNearestNeighborLatLonSear**ch(layer,
>>>> > dist).sort("**OrthodromicDistance").**copyDatabaseRecordProperties(**keys). range(low,
>>>> > high);
>>>> > Now to iterate over this GeoPipline, I am using hasNext() / next()
>>>> > 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
>>>> > way to find the nearest places. The layer has 10 million entries.
>>>> > Regards
>>>> > Abhijeet
>>>> > --