Lucene - Core
  1. Lucene - Core
  2. LUCENE-2641

BaseTestRangeFilter can be extremely slow

    Details

    • Type: Test Test
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.1, 4.0-ALPHA
    • Component/s: general/test
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      The tests that extend BaseTestRangeFilter can sometimes be very slow:
      TestFieldCacheRangeFilter, TestMultiTermConstantScore, TestTermRangeFilter

      for example, TestFieldCacheRangeFilter just ran for 10 minutes on my computer before I killed it,
      but i noticed these tests frequently run for over a minute.

      I think at the least we should change these to junit4 so the index is built once in @beforeClass

      1. LUCENE-2641.patch
        37 kB
        Robert Muir
      2. LUCENE-2641.patch
        37 kB
        Robert Muir
      3. LUCENE-2641.patch
        40 kB
        Robert Muir

        Activity

        Hide
        Robert Muir added a comment -

        here's an initial patch.

        i tried to fix some worst-case problems with similar tests as well, but some
        still have problems...

        Show
        Robert Muir added a comment - here's an initial patch. i tried to fix some worst-case problems with similar tests as well, but some still have problems...
        Hide
        Robert Muir added a comment -

        here's an updated patch that speeds up the worst of the tests.

        additionally we found 2 bugs in preflex codec that caused tests to be very slow under preflex.

        Show
        Robert Muir added a comment - here's an updated patch that speeds up the worst of the tests. additionally we found 2 bugs in preflex codec that caused tests to be very slow under preflex.
        Hide
        Robert Muir added a comment -

        sorry! wrong patch. (I accidentally uploaded the old one again last time)

        Show
        Robert Muir added a comment - sorry! wrong patch. (I accidentally uploaded the old one again last time)
        Hide
        Robert Muir added a comment -

        Committed revision 996357, 996360 (3x).

        we can always look out for more tests like this and handle them on a case by case basis,

        In general if it creates a huge index, we should ensure reasonable maxBufferedDocs etc,
        and if it has a ton of methods that don't modify the index, we should consider creating the index in @BeforeClass

        But i think the "crazy" defaults in newIndexWriterConfig are reasonable, given most tests
        only use a tiny amount of documents.

        Show
        Robert Muir added a comment - Committed revision 996357, 996360 (3x). we can always look out for more tests like this and handle them on a case by case basis, In general if it creates a huge index, we should ensure reasonable maxBufferedDocs etc, and if it has a ton of methods that don't modify the index, we should consider creating the index in @BeforeClass But i think the "crazy" defaults in newIndexWriterConfig are reasonable, given most tests only use a tiny amount of documents.
        Hide
        Grant Ingersoll added a comment -

        Bulk close for 3.1

        Show
        Grant Ingersoll added a comment - Bulk close for 3.1

          People

          • Assignee:
            Unassigned
            Reporter:
            Robert Muir
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development