>
> On a side note, what do you need System.exit(0); for ? You should
> close the SessionFactory.
>
Because i m better with geo/data than with code =)
Thanks for pointing me the right direction.
The last numbers series is from a 50k calls run in radian mode that lasted
45 minutes.
For each center
Hi Nicolas, thanks looking better.
Could you now change it for longer runs? If I think of 2K invocations,
each taking 5ms, that's not more than 10 seconds.. It took me several
minutes to load all the data needed for the test, then just some
seconds to run the tests.. not worth the load time ;)
To c
>
> maybe even simpler set a constant as the seed of your random
> generator: should provide a reproducible sequence of values.
/facepalm
I should have guess that :s
Niko
> >>
> >> On 11 May 2012 08:40, Nicolas Helleringer <
> nicolas.hellerin...@gmail.com>
> >> wrote:
> >> > There, back and a
On 14 May 2012 21:36, Nicolas Helleringer wrote:
> Hi Sanne,
>
>> # Functionality
>> Why is the number of documents fetched via Degrees approximately half
>> of what you're fetching via Radians?
>
> The test is randomized at this time. I do not have a fixed test set :s sorry
> In one run the same
Hi Sanne,
# Functionality
> Why is the number of documents fetched via Degrees approximately half
> of what you're fetching via Radians?
>
The test is randomized at this time. I do not have a fixed test set :s sorry
In one run the same points are use for the 4 type of request.
But switching radia
Hi Nicolas,
thanks for the numbers, very interesting. I have two main questions on this:
# Functionality
Why is the number of documents fetched via Degrees approximately half
of what you're fetching via Radians?
This seems to be true for both "Grid" and "DoubleRange", while the
numbers (approxima
There, back and again ...
After fixing a bug in grid search here are some updated results on 2k calls
Degrees :
Mean time with Grid : 4.4897266425641025 ms. Average number of docs
fetched : 2506.96
Mean time with Grid + Distance filter : 6.4930799487179485 ms. Average
number of docs fetched : 4
Here are some results :
Mean time with Grid : 4.9297471630769225 ms. Average number of docs
fetched : 2416.373846153846
Mean time with Grid + Distance filter : 6.48634534 ms. Average number of
docs fetched : 425.84
Mean time with DoubleRange : 15.39593650051282 ms. Average number of docs
fetche
Do you know the average amount of POI that were filtered in memory but the
DistanceFilter during these runs?
Emmanuel
On 7 mai 2012, at 10:31, Nicolas Helleringer wrote:
> Hi all,
>
> I have done a radian patch/branch and some benchmarks on geonames french
> database.
>
> Benchs are on 2k ca
Hi all,
I have done a radian patch/branch and some benchmarks on geonames french
database.
Benchs are on 2k calls each run.
Radians:
run 1
Mean time with Grid : 4.808043092820513 ms
Mean time with Grid + Distance filter : 6.571108878461538 ms
Mean time with DoubleRange : 14.62661525128205 ms
Mea
On May 3, 2012 10:10 AM, "Emmanuel Bernard" wrote:
>
> How comes the DistanceFilter has to compute the distance for the whole
corpus?
You're right in that's not always the case, but it's possible. If there are
more filters enabled and they are executed first, our filter will need to
do the math o
Correct.
On 3 May 2012 10:07, Emmanuel Bernard wrote:
> Let me see if I understood by rephrasing. I am trying to get a feel of where
> conversions happen.
>
> I am assuming that this is mostly relevant for the boolean query approach and
> the later circle memory filtering (ie that quad tree is
2012/5/3 Emmanuel Bernard
> Let me see if I understood by rephrasing. I am trying to get a feel of
> where conversions happen.
>
> I am assuming that this is mostly relevant for the boolean query approach
> and the later circle memory filtering (ie that quad tree is not involved).
>
In Quad Tree
2012/5/3 Sanne Grinovero
> The reason for my comment is that the code is doing a conversion to
> radians in the DistanceFilter, which needs to be extremely efficient
> as it's not only applied on the resultset but potentially on the whole
> corpus of all Documents in the index.
> So even if it's
How comes the DistanceFilter has to compute the distance for the whole corpus?
By the way the actual storage (say via Hibernate ORM, or Infinispan) does not
need to store in radian, so we don't need to do a conversion when reading an
entity.
On 3 mai 2012, at 10:45, Sanne Grinovero wrote:
> Th
Let me see if I understood by rephrasing. I am trying to get a feel of where
conversions happen.
I am assuming that this is mostly relevant for the boolean query approach and
the later circle memory filtering (ie that quad tree is not involved).
Today we accept decimal coordinates from the user
The reason for my comment is that the code is doing a conversion to
radians in the DistanceFilter, which needs to be extremely efficient
as it's not only applied on the resultset but potentially on the whole
corpus of all Documents in the index.
So even if it's true that conversion would be needed
Hi all,
Sanne and I have been wondering about the way the spatial
branch/module/functionality for Hibernate Search shall store its
coordinates in the Lucene index.
Today it is implemented with decimal degree for :
- easy debugging/readability
- ease of conversion on storage as we want to accept m
18 matches
Mail list logo
