[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14647540#comment-14647540
]
Nicholas Knize commented on LUCENE-6699:
----------------------------------------
bq. Right, but you'd be comparing 2 sines, 2 cosines, and 1 sqrt against only
the cost of unpacking
Encoding/Decoding ECEF into 96 Bits:
{noformat}
Avg computation: 664.6969666857143 ns Trials: 35000000 Total time:
23264.393834 ms
Avg computation: 664.829008375 ns Trials: 40000000 Total time: 26593.160335 ms
Avg computation: 667.3625471333334 ns Trials: 45000000 Total time:
30031.314621 ms
Avg computation: 668.46880436 ns Trials: 50000000 Total time: 33423.440218 ms
Avg computation: 667.8703028909091 ns Trials: 55000000 Total time:
36732.866659 ms
Avg computation: 669.3753888666666 ns Trials: 60000000 Total time:
40162.523332 ms
Avg computation: 668.4362739230769 ns Trials: 65000000 Total time:
43448.357805 ms
Avg computation: 667.9539851 ns Trials: 70000000 Total time: 46756.778957 ms
Avg computation: 667.3638297333333 ns Trials: 75000000 Total time:
50052.28723 ms
Avg computation: 675.024778375 ns Trials: 80000000 Total time: 54001.98227 ms
Avg computation: 674.1673578352941 ns Trials: 85000000 Total time:
57304.225416 ms
Avg computation: 673.4723439777778 ns Trials: 90000000 Total time:
60612.510958 ms
Avg computation: 673.0372402842105 ns Trials: 95000000 Total time:
63938.537827 ms
Avg computation: 672.55224382 ns Trials: 100000000 Total time: 67255.224382 ms
{noformat}
Compared to packing/unpacking lat/lon into 64 bits using using GeoPointField
morton bit twiddling:
{noformat}
Avg computation: 60.397136 ns Trials: 35000000 Total time: 2113.89976 ms
Avg computation: 61.6391708 ns Trials: 40000000 Total time: 2465.566832 ms
Avg computation: 62.744074222222224 ns Trials: 45000000 Total time:
2823.48334 ms
Avg computation: 63.51111108 ns Trials: 50000000 Total time: 3175.555554 ms
Avg computation: 64.18207294545455 ns Trials: 55000000 Total time:
3530.014012 ms
Avg computation: 64.73684656666667 ns Trials: 60000000 Total time:
3884.210794 ms
Avg computation: 65.18073341538461 ns Trials: 65000000 Total time:
4236.747672 ms
Avg computation: 65.5902512 ns Trials: 70000000 Total time: 4591.317584 ms
Avg computation: 65.02902253333333 ns Trials: 75000000 Total time: 4877.17669
ms
Avg computation: 63.6249806 ns Trials: 80000000 Total time: 5089.998448 ms
Avg computation: 62.4193206 ns Trials: 85000000 Total time: 5305.642251 ms
Avg computation: 61.344433977777776 ns Trials: 90000000 Total time:
5520.999058 ms
Avg computation: 61.402236642105265 ns Trials: 95000000 Total time:
5833.212481 ms
Avg computation: 61.10019762 ns Trials: 100000000 Total time: 6110.019762 ms
{noformat}
So using the 3D BitSet approach is 10 times longer, with the obvious culprit
being the for loop for each bit. This can be optimized, though, using a 3-way
bit twiddle and 2 longs if a 64 bit 3D packing yields unacceptable loss of
precision.
> Integrate lat/lon BKD and spatial3d
> -----------------------------------
>
> Key: LUCENE-6699
> URL: https://issues.apache.org/jira/browse/LUCENE-6699
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Attachments: Geo3DPacking.java
>
>
> I'm opening this for discussion, because I'm not yet sure how to do
> this integration, because of my ignorance about spatial in general and
> spatial3d in particular :)
> Our BKD tree impl is very fast at doing lat/lon shape intersection
> (bbox, polygon, soon distance: LUCENE-6698) against previously indexed
> points.
> I think to integrate with spatial3d, we would first need to record
> lat/lon/z into doc values. Somewhere I saw discussion about how we
> could stuff all 3 into a single long value with acceptable precision
> loss? Or, we could use BinaryDocValues? We need all 3 dims available
> to do the fast per-hit query time filtering.
> But, second: what do we index into the BKD tree? Can we "just" index
> earth surface lat/lon, and then at query time is spatial3d able to
> give me an enclosing "surface lat/lon" bbox for a 3d shape? Or
> ... must we index all 3 dimensions into the BKD tree (seems like this
> could be somewhat wasteful)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
