• Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 6.1, 7.0
    • None
    • None
    • New


      This crutch doesn't speed up most polygons anymore, only some very complex ones with many components/holes.

      Instead as a simple step, we can use a tree of components (organized by bounding box x-intervals just like edges). This makes things less trappy for crazy polygons like the russia one.

      Synthetic polygons from luceneUtil

      vertices old QPS new QPS
      5 40.5 43.8
      50 33.1 32.8
      500 31.9 31.9
      5000 29.4 29.6
      50000 20.4 22.8
      500000 4.0 6.9

      Real polygons (33 london districts:

      vertices old QPS new QPS
      avg 5.6k 113.8 105.4

      Russia geonames polygon (> 1000 components, crosses dateline, hugs poles, you name it)

      vertices old QPS new QPS
      11598 1.17 5.35

      The grid hurts russia (keeping it around -> 4 QPS), and you can see it also hurts all the synthetic ones. Those london boundaries hit a sweet spot where it helps just a tad but, I think we should remove it and its startup cost along with it.

      We can probably organize the tree better to be more efficient with many components: for contains() we could just pack them all into one poly. But i'm worried what this will do for relations (there would be fake edges between components i think?), and it would be complicated.


        1. LUCENE-7251.patch
          103 kB
          Robert Muir
        2. LUCENE-7251.patch
          25 kB
          Robert Muir

        Issue Links



              Unassigned Unassigned
              rcmuir Robert Muir
              0 Vote for this issue
              2 Start watching this issue