Lucene - Core
  1. Lucene - Core
  2. LUCENE-4322

Can we make oal.util.packed.BulkOperation* smaller?

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0, 6.0
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      These source files add up to a lot of sources ... it caused problems when compiling under Maven and InteliJ.

      I committed a change to make separates files, but in aggregate this is still a lot ...

      EG maybe we don't need to specialize encode?

      1. LUCENE-4322.patch
        1.73 MB
        Adrien Grand
      2. LUCENE-4322-2.patch
        830 kB
        Adrien Grand

        Activity

        Hide
        Adrien Grand added a comment -

        Having a specialized encode can be important for GrowableWriter performance (this method is used every time the number of bits per value needs to be changed).

        Now that BulkOperation.java has been splitted, I think everything compiles under Maven and Intellij . Why do we still need to make these files smaller?

        If we really need to make these classes smaller, maybe we could first stop specializing encode for int[] values when bitsPerValue > 32. I can't think of a use-case this method could be useful to.

        Show
        Adrien Grand added a comment - Having a specialized encode can be important for GrowableWriter performance (this method is used every time the number of bits per value needs to be changed). Now that BulkOperation.java has been splitted, I think everything compiles under Maven and Intellij . Why do we still need to make these files smaller? If we really need to make these classes smaller, maybe we could first stop specializing encode for int[] values when bitsPerValue > 32. I can't think of a use-case this method could be useful to.
        Hide
        Dawid Weiss added a comment -

        I looked into those files briefly so this may not be applicable but if possible make them use loops instead of manually unrolling the code in Java. JIT will typically unroll loops anyway depending on the environment and those unrolled JIT loops are faster than java-unrolled loops (because certain bounds checks can be eliminated).

        Show
        Dawid Weiss added a comment - I looked into those files briefly so this may not be applicable but if possible make them use loops instead of manually unrolling the code in Java. JIT will typically unroll loops anyway depending on the environment and those unrolled JIT loops are faster than java-unrolled loops (because certain bounds checks can be eliminated).
        Hide
        Michael McCandless added a comment -

        Actually the size increase wasn't as bad as I thought ... Lucene core JAR is 2.3 MB in 4.0 Beta and now it's 2.7 MB.

        So I agree the immediate problem (can't compile in some envs) is fixed ... so making these smaller isn't really important.

        Still if we have pointless code (int[] values with bpv > 32) we should remove it.

        And Dawid's idea sounds compelling if it could make things faster!

        Show
        Michael McCandless added a comment - Actually the size increase wasn't as bad as I thought ... Lucene core JAR is 2.3 MB in 4.0 Beta and now it's 2.7 MB. So I agree the immediate problem (can't compile in some envs) is fixed ... so making these smaller isn't really important. Still if we have pointless code (int[] values with bpv > 32) we should remove it. And Dawid's idea sounds compelling if it could make things faster!
        Hide
        Dawid Weiss added a comment -

        It shouldn't make anything slower, really. There are several reasons – loop unrolling at jit time is one, but then there are also jit codegen limits (too big methods won't even jit, ever), cpu cache considerations (jitted code will be larger than a loop), etc.

        Show
        Dawid Weiss added a comment - It shouldn't make anything slower, really. There are several reasons – loop unrolling at jit time is one, but then there are also jit codegen limits (too big methods won't even jit, ever), cpu cache considerations (jitted code will be larger than a loop), etc.
        Hide
        Robert Muir added a comment -

        Actually the size increase wasn't as bad as I thought ... Lucene core JAR is 2.3 MB in 4.0 Beta and now it's 2.7 MB.

        this is surprising, it used to be like 1MB. Its scary to me its 2.7MB even though we pulled out large generated code like queryparser and standardtokenizer. I think we need to investigate what happened here.

        Show
        Robert Muir added a comment - Actually the size increase wasn't as bad as I thought ... Lucene core JAR is 2.3 MB in 4.0 Beta and now it's 2.7 MB. this is surprising, it used to be like 1MB. Its scary to me its 2.7MB even though we pulled out large generated code like queryparser and standardtokenizer. I think we need to investigate what happened here.
        Hide
        Michael McCandless added a comment -

        I think we need to investigate what happened here.

        +1

        In 3.6.1 it's 1.5M. For the longest time we were under 1M! That was impressive

        Show
        Michael McCandless added a comment - I think we need to investigate what happened here. +1 In 3.6.1 it's 1.5M. For the longest time we were under 1M! That was impressive
        Hide
        Robert Muir added a comment -

        In 3.6.1 it's 1.5M.

        A lot of that is because it supports several grammars of StandardTokenizer/UAX29URLEMailTokenizer/ClassicTokenizer and still has queryparser.

        All of this was removed in core. 4.0 should be 1MB.

        If we have megabytes of generated specialized code, we should remove all of this and replace it with a simple loop. Then each optimization should be re-introduced one by one based on its space/time tradeoff.

        We certainly dont need optimizations for bits per value > anything like 4 or 5 I think. 32 is outlandish, just use an int[]

        Show
        Robert Muir added a comment - In 3.6.1 it's 1.5M. A lot of that is because it supports several grammars of StandardTokenizer/UAX29URLEMailTokenizer/ClassicTokenizer and still has queryparser. All of this was removed in core. 4.0 should be 1MB. If we have megabytes of generated specialized code, we should remove all of this and replace it with a simple loop. Then each optimization should be re-introduced one by one based on its space/time tradeoff. We certainly dont need optimizations for bits per value > anything like 4 or 5 I think. 32 is outlandish, just use an int[]
        Hide
        Adrien Grand added a comment -

        All of this was removed in core. 4.0 should be 1MB.

        Even when removing the whole oal.util.packed package, the JAR size is still 2.1MB.

        We certainly dont need optimizations for bits per value > anything like 4 or 5 I think. 32 is outlandish, just use an int[].

        These classes are not only used to store large int arrays in memory but also to perform encoding/decoding of short sequences, such as in BlockPF. If we want BlockPF to remain fast, 5 is probably too low. Mike tested BlockPF with an unspecialized decoder and it showed a great performance loss : https://issues.apache.org/jira/browse/LUCENE-3892?focusedCommentId=13431491&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13431491

        Show
        Adrien Grand added a comment - All of this was removed in core. 4.0 should be 1MB. Even when removing the whole oal.util.packed package, the JAR size is still 2.1MB. We certainly dont need optimizations for bits per value > anything like 4 or 5 I think. 32 is outlandish, just use an int[]. These classes are not only used to store large int arrays in memory but also to perform encoding/decoding of short sequences, such as in BlockPF. If we want BlockPF to remain fast, 5 is probably too low. Mike tested BlockPF with an unspecialized decoder and it showed a great performance loss : https://issues.apache.org/jira/browse/LUCENE-3892?focusedCommentId=13431491&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13431491
        Hide
        Robert Muir added a comment -

        Even when removing the whole oal.util.packed package, the JAR size is still 2.1MB.

        Right, I don't mean to complain about the packed package or single it out (though I have concerns about the massive specialization),
        I was pointing out the larger issue of bloat. There are definitely other problems too.

        These classes are not only used to store large int arrays in memory but also to perform encoding/decoding of short sequences, such as in BlockPF. If we want BlockPF to remain fast, 5 is probably too low. Mike tested BlockPF with an unspecialized decoder and it showed a great performance loss : https://issues.apache.org/jira/browse/LUCENE-3892?focusedCommentId=13431491&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13431491

        But I don't think an unspecialized decoder is necessarily fair. I think we could optimize the low bpv that we would find in freqs/positions and then have a unspecialized fallback or whatever.

        I have concerns that specializing every bpv just means that nothing is even getting JITd and actually makes things worse.

        Show
        Robert Muir added a comment - Even when removing the whole oal.util.packed package, the JAR size is still 2.1MB. Right, I don't mean to complain about the packed package or single it out (though I have concerns about the massive specialization), I was pointing out the larger issue of bloat. There are definitely other problems too. These classes are not only used to store large int arrays in memory but also to perform encoding/decoding of short sequences, such as in BlockPF. If we want BlockPF to remain fast, 5 is probably too low. Mike tested BlockPF with an unspecialized decoder and it showed a great performance loss : https://issues.apache.org/jira/browse/LUCENE-3892?focusedCommentId=13431491&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13431491 But I don't think an unspecialized decoder is necessarily fair. I think we could optimize the low bpv that we would find in freqs/positions and then have a unspecialized fallback or whatever. I have concerns that specializing every bpv just means that nothing is even getting JITd and actually makes things worse.
        Hide
        Michael McCandless added a comment -

        I swept the full Wikipedia (05/12 export) index to count how many blocks we see for each bitsPerValue:

         0 bits:  0.8% blocks=540300
         1 bits:  0.0% blocks=38
         2 bits:  6.9% blocks=4614597
         3 bits: 13.5% blocks=9069600
         4 bits:  6.7% blocks=4480753
         5 bits:  2.8% blocks=1875920
         6 bits:  2.8% blocks=1867222
         7 bits:  8.0% blocks=5394210
         8 bits: 39.4% blocks=26435409
         9 bits:  3.4% blocks=2271263
        10 bits:  3.2% blocks=2114455
        11 bits:  2.8% blocks=1910650
        12 bits:  2.5% blocks=1670494
        13 bits:  2.1% blocks=1383284
        14 bits:  1.6% blocks=1091507
        15 bits:  1.3% blocks=855881
        16 bits:  1.0% blocks=643360
        17 bits:  0.6% blocks=421664
        18 bits:  0.4% blocks=256929
        19 bits:  0.2% blocks=132227
        20 bits:  0.0% blocks=31852
        21 bits:  0.0% blocks=11753
        22 bits:  0.0% blocks=7176
        23 bits:  0.0% blocks=1168
        

        The 0 bits case means all values are the same (eg all 1s).

        Show
        Michael McCandless added a comment - I swept the full Wikipedia (05/12 export) index to count how many blocks we see for each bitsPerValue: 0 bits: 0.8% blocks=540300 1 bits: 0.0% blocks=38 2 bits: 6.9% blocks=4614597 3 bits: 13.5% blocks=9069600 4 bits: 6.7% blocks=4480753 5 bits: 2.8% blocks=1875920 6 bits: 2.8% blocks=1867222 7 bits: 8.0% blocks=5394210 8 bits: 39.4% blocks=26435409 9 bits: 3.4% blocks=2271263 10 bits: 3.2% blocks=2114455 11 bits: 2.8% blocks=1910650 12 bits: 2.5% blocks=1670494 13 bits: 2.1% blocks=1383284 14 bits: 1.6% blocks=1091507 15 bits: 1.3% blocks=855881 16 bits: 1.0% blocks=643360 17 bits: 0.6% blocks=421664 18 bits: 0.4% blocks=256929 19 bits: 0.2% blocks=132227 20 bits: 0.0% blocks=31852 21 bits: 0.0% blocks=11753 22 bits: 0.0% blocks=7176 23 bits: 0.0% blocks=1168 The 0 bits case means all values are the same (eg all 1s).
        Hide
        Michael McCandless added a comment -

        Results on the full Meme index (http://snap.stanford.edu/data/memetracker9.html), 211M docs:

        0 bits:  1.9% blocks=1350821
        1 bits:  0.0% blocks=649
        2 bits: 18.5% blocks=13112234
        3 bits:  9.1% blocks=6487129
        4 bits:  2.6% blocks=1865845
        5 bits:  2.8% blocks=2006701
        6 bits:  8.9% blocks=6344910
        7 bits: 17.1% blocks=12133598
        8 bits: 12.4% blocks=8811848
        9 bits:  6.5% blocks=4646619
        10 bits:  3.8% blocks=2696347
        11 bits:  3.0% blocks=2162407
        12 bits:  2.8% blocks=1965635
        13 bits:  2.5% blocks=1758592
        14 bits:  2.1% blocks=1469763
        15 bits:  1.7% blocks=1204291
        16 bits:  1.3% blocks=950651
        17 bits:  0.9% blocks=647747
        18 bits:  0.6% blocks=461223
        19 bits:  0.5% blocks=345580
        20 bits:  0.4% blocks=252739
        21 bits:  0.3% blocks=180809
        22 bits:  0.2% blocks=120015
        23 bits:  0.1% blocks=56358
        24 bits:  0.0% blocks=12463
        25 bits:  0.0% blocks=4242
        26 bits:  0.0% blocks=2077
        27 bits:  0.0% blocks=374
        
        Show
        Michael McCandless added a comment - Results on the full Meme index ( http://snap.stanford.edu/data/memetracker9.html ), 211M docs: 0 bits: 1.9% blocks=1350821 1 bits: 0.0% blocks=649 2 bits: 18.5% blocks=13112234 3 bits: 9.1% blocks=6487129 4 bits: 2.6% blocks=1865845 5 bits: 2.8% blocks=2006701 6 bits: 8.9% blocks=6344910 7 bits: 17.1% blocks=12133598 8 bits: 12.4% blocks=8811848 9 bits: 6.5% blocks=4646619 10 bits: 3.8% blocks=2696347 11 bits: 3.0% blocks=2162407 12 bits: 2.8% blocks=1965635 13 bits: 2.5% blocks=1758592 14 bits: 2.1% blocks=1469763 15 bits: 1.7% blocks=1204291 16 bits: 1.3% blocks=950651 17 bits: 0.9% blocks=647747 18 bits: 0.6% blocks=461223 19 bits: 0.5% blocks=345580 20 bits: 0.4% blocks=252739 21 bits: 0.3% blocks=180809 22 bits: 0.2% blocks=120015 23 bits: 0.1% blocks=56358 24 bits: 0.0% blocks=12463 25 bits: 0.0% blocks=4242 26 bits: 0.0% blocks=2077 27 bits: 0.0% blocks=374
        Hide
        Robert Muir added a comment -

        based on this, can we just specialize 2, 3, 6, 7, 8 or something like that?

        Show
        Robert Muir added a comment - based on this, can we just specialize 2, 3, 6, 7, 8 or something like that?
        Hide
        Adrien Grand added a comment -

        These numbers depend on so many factors (docFreq distribution, order in which documents have been indexed, etc.) that it sounds strange to me to only pick a few bits per value we would like to keep specialized based on these benchmarks. I think it would make more sense to specialize a full range?

        I have concerns that specializing every bpv just means that nothing is even getting JITd and actually makes things worse.

        I have the same concerns but on the other hand if we pick too few numbers of bits per value, BlockFor might show very disappointing performance with different datasets.

        Maybe something more conservative would be to specialize the [1-24] range. It would already make the JAR ~350kb smaller (if we removed all specialized impls, the JAR would be ~500kb smaller). Removing all encoder specializations would probably help us save another 50kb.

        Show
        Adrien Grand added a comment - These numbers depend on so many factors (docFreq distribution, order in which documents have been indexed, etc.) that it sounds strange to me to only pick a few bits per value we would like to keep specialized based on these benchmarks. I think it would make more sense to specialize a full range? I have concerns that specializing every bpv just means that nothing is even getting JITd and actually makes things worse. I have the same concerns but on the other hand if we pick too few numbers of bits per value, BlockFor might show very disappointing performance with different datasets. Maybe something more conservative would be to specialize the [1-24] range. It would already make the JAR ~350kb smaller (if we removed all specialized impls, the JAR would be ~500kb smaller). Removing all encoder specializations would probably help us save another 50kb.
        Hide
        Adrien Grand added a comment -

        It looks like one of the reasons of the size increase of lucene-core.jar is its number of classes. Although some code has been moved to modules, its number of classes has increased from 972 in 3.6.1 to 1471 in trunk.

        Show
        Adrien Grand added a comment - It looks like one of the reasons of the size increase of lucene-core.jar is its number of classes. Although some code has been moved to modules, its number of classes has increased from 972 in 3.6.1 to 1471 in trunk.
        Hide
        Adrien Grand added a comment -

        Patch that tries to reduce the JAR size:

        • unspecialized encode methods,
        • specialized decode methods only when 0 < bitsPerValue <= 24.

        Overall, it makes the core jar 361kb bytes smaller (2700542 bytes before applying the patch, 2330514 after).

        I ran a quick run of lucene-util in debug mode with blockPostingsFormat=For and it showed no performance difference.

        Show
        Adrien Grand added a comment - Patch that tries to reduce the JAR size: unspecialized encode methods, specialized decode methods only when 0 < bitsPerValue <= 24. Overall, it makes the core jar 361kb bytes smaller (2700542 bytes before applying the patch, 2330514 after). I ran a quick run of lucene-util in debug mode with blockPostingsFormat=For and it showed no performance difference.
        Hide
        Michael McCandless added a comment -

        Patch looks good! That's a nice reduction.

        Too bad we have to duplicate decode 4 times (from long[]/byte[] to long[]/int[]).

        We could still shrink things further by doing less loop unrolling ourselves? Eg for BulkOperationPacked2, when decoding from byte[], that code is replicated 8 times but could be done as just 8* iters.

        Show
        Michael McCandless added a comment - Patch looks good! That's a nice reduction. Too bad we have to duplicate decode 4 times (from long[]/byte[] to long[]/int[]). We could still shrink things further by doing less loop unrolling ourselves? Eg for BulkOperationPacked2, when decoding from byte[], that code is replicated 8 times but could be done as just 8* iters.
        Hide
        Adrien Grand added a comment -

        We could still shrink things further by doing less loop unrolling ourselves? Eg for BulkOperationPacked2, when decoding from byte[], that code is replicated 8 times but could be done as just 8* iters.

        Yes, I had planned to work on it too! Unless someone doesn't like my last patch, I'll commit it and will start working on this loop unrolling issue soon...

        Show
        Adrien Grand added a comment - We could still shrink things further by doing less loop unrolling ourselves? Eg for BulkOperationPacked2, when decoding from byte[], that code is replicated 8 times but could be done as just 8* iters. Yes, I had planned to work on it too! Unless someone doesn't like my last patch, I'll commit it and will start working on this loop unrolling issue soon...
        Hide
        Robert Muir added a comment -

        +1 for the first iteration.

        Show
        Robert Muir added a comment - +1 for the first iteration.
        Hide
        Michael McCandless added a comment -

        +1 for the first iteration.

        Show
        Michael McCandless added a comment - +1 for the first iteration.
        Hide
        Dawid Weiss added a comment -

        Good idea, Andrien. More classes are definitely worse than more static methods, this is a normal result of how ZIP format works (each file is encoded individually, compression dictionaries are inefficient for many small files).

        Show
        Dawid Weiss added a comment - Good idea, Andrien. More classes are definitely worse than more static methods, this is a normal result of how ZIP format works (each file is encoded individually, compression dictionaries are inefficient for many small files).
        Hide
        Uwe Schindler added a comment -

        +1!! Smaller, smaller, smaller

        Show
        Uwe Schindler added a comment - +1!! Smaller, smaller, smaller
        Hide
        Adrien Grand added a comment -

        New iteration.

        This patch makes the JAR 84kB smaller (now 2243513 bytes) by :
        1.removing the specializations for BulkOperationPackedSingleBlock,
        2. rolling back some loops,
        3. removing the assertions on the buffer sizes (that were rather useless).

        I removed the specializations for BulkOperationPackedSingleBlock because the default version is already rather fast (it has no conditions). For example, for bitsPerValue=4, BulkOperationPackedSingleBlock is only ~20-30% slower than BulkOperationPacked4 and BulkOperationPackedSingleBlock4, while BulkOperationPacked is ~300% slower.

        Moreover I rolled back some loops (especially the decode(byte[],...) are now 8 times shorter).

        I ran a benchmark between this patch and current trunk to make sure these changes don't hurt the Block postings format performance ('local' means patch applied):

                        Task   QPS trunkStdDev trunk   QPS localStdDev local      Pct diff
                 LowSpanNear       28.22        0.81       27.11        1.64  -12% -    4%
                 MedSpanNear        8.86        0.30        8.63        0.47  -11% -    6%
                HighSpanNear        7.59        0.24        7.42        0.42  -10% -    6%
                     MedTerm      965.02       26.52      947.64       22.67   -6% -    3%
                    HighTerm      265.84        9.09      262.46        5.01   -6% -    4%
                  HighPhrase        9.43        1.17        9.41        1.23  -22% -   28%
                    PKLookup      249.61       10.58      250.46        8.97   -7% -    8%
                  OrHighHigh       58.76        2.22       59.09        3.13   -8% -   10%
                   LowPhrase       76.16        2.73       76.82        3.24   -6% -    9%
                   OrHighLow      140.83        5.06      142.33        7.41   -7% -   10%
                   MedPhrase       60.21        2.81       60.92        3.28   -8% -   11%
                   OrHighMed      136.16        4.81      138.12        7.21   -7% -   10%
             LowSloppyPhrase       81.25        2.17       82.80        2.82   -4% -    8%
                     Respell       91.72        4.07       93.47        2.21   -4% -    9%
                     Prefix3      251.63        8.73      256.48        6.61   -4% -    8%
                 AndHighHigh      136.17        2.20      138.95        2.85   -1% -    5%
            HighSloppyPhrase       14.17        0.66       14.46        0.74   -7% -   12%
                    Wildcard      185.86        5.38      190.23        3.38   -2% -    7%
                      IntNRQ       63.10        6.93       64.65        2.58  -11% -   19%
             MedSloppyPhrase       25.48        1.05       26.27        1.17   -5% -   12%
                      Fuzzy1      106.76        4.83      110.17        2.44   -3% -   10%
                  AndHighLow     2650.35       53.66     2739.95       58.80    0% -    7%
                      Fuzzy2       35.45        1.95       36.75        0.99   -4% -   12%
                  AndHighMed      357.48        5.31      370.88        6.77    0% -    7%
                     LowTerm     2211.45       89.59     2298.23      104.62   -4% -   13%
        

        This looks good to me.

        I think there are maybe a few things we could still do to reduce the JAR size but I'm worried that there would be little gain compared to the increased complexity of these classes.

        I just tried to remove all BulkOperation* specializations, and it only made the JAR 52kb smaller compared to this patch, so maybe we should stop here? There's already been a lot of progress!

        Show
        Adrien Grand added a comment - New iteration. This patch makes the JAR 84kB smaller (now 2243513 bytes) by : 1.removing the specializations for BulkOperationPackedSingleBlock, 2. rolling back some loops, 3. removing the assertions on the buffer sizes (that were rather useless). I removed the specializations for BulkOperationPackedSingleBlock because the default version is already rather fast (it has no conditions). For example, for bitsPerValue=4, BulkOperationPackedSingleBlock is only ~20-30% slower than BulkOperationPacked4 and BulkOperationPackedSingleBlock4, while BulkOperationPacked is ~300% slower. Moreover I rolled back some loops (especially the decode(byte[],...) are now 8 times shorter). I ran a benchmark between this patch and current trunk to make sure these changes don't hurt the Block postings format performance ('local' means patch applied): Task QPS trunkStdDev trunk QPS localStdDev local Pct diff LowSpanNear 28.22 0.81 27.11 1.64 -12% - 4% MedSpanNear 8.86 0.30 8.63 0.47 -11% - 6% HighSpanNear 7.59 0.24 7.42 0.42 -10% - 6% MedTerm 965.02 26.52 947.64 22.67 -6% - 3% HighTerm 265.84 9.09 262.46 5.01 -6% - 4% HighPhrase 9.43 1.17 9.41 1.23 -22% - 28% PKLookup 249.61 10.58 250.46 8.97 -7% - 8% OrHighHigh 58.76 2.22 59.09 3.13 -8% - 10% LowPhrase 76.16 2.73 76.82 3.24 -6% - 9% OrHighLow 140.83 5.06 142.33 7.41 -7% - 10% MedPhrase 60.21 2.81 60.92 3.28 -8% - 11% OrHighMed 136.16 4.81 138.12 7.21 -7% - 10% LowSloppyPhrase 81.25 2.17 82.80 2.82 -4% - 8% Respell 91.72 4.07 93.47 2.21 -4% - 9% Prefix3 251.63 8.73 256.48 6.61 -4% - 8% AndHighHigh 136.17 2.20 138.95 2.85 -1% - 5% HighSloppyPhrase 14.17 0.66 14.46 0.74 -7% - 12% Wildcard 185.86 5.38 190.23 3.38 -2% - 7% IntNRQ 63.10 6.93 64.65 2.58 -11% - 19% MedSloppyPhrase 25.48 1.05 26.27 1.17 -5% - 12% Fuzzy1 106.76 4.83 110.17 2.44 -3% - 10% AndHighLow 2650.35 53.66 2739.95 58.80 0% - 7% Fuzzy2 35.45 1.95 36.75 0.99 -4% - 12% AndHighMed 357.48 5.31 370.88 6.77 0% - 7% LowTerm 2211.45 89.59 2298.23 104.62 -4% - 13% This looks good to me. I think there are maybe a few things we could still do to reduce the JAR size but I'm worried that there would be little gain compared to the increased complexity of these classes. I just tried to remove all BulkOperation* specializations, and it only made the JAR 52kb smaller compared to this patch, so maybe we should stop here? There's already been a lot of progress!
        Hide
        Robert Muir added a comment -

        +1 to commit. Thanks for doing all of this Adrien!

        Show
        Robert Muir added a comment - +1 to commit. Thanks for doing all of this Adrien!
        Hide
        Adrien Grand added a comment -

        NP Robert, I'm happy to help, thanks for reviewing!

        I just committed (r1379479 and r1379489 on trunk, 1379491 on branch 4.x). Do we agree on closing this issue now?

        Show
        Adrien Grand added a comment - NP Robert, I'm happy to help, thanks for reviewing! I just committed (r1379479 and r1379489 on trunk, 1379491 on branch 4.x). Do we agree on closing this issue now?
        Hide
        Robert Muir added a comment -

        +1

        Show
        Robert Muir added a comment - +1
        Hide
        Uwe Schindler added a comment -

        Closed after release.

        Show
        Uwe Schindler added a comment - Closed after release.

          People

          • Assignee:
            Unassigned
            Reporter:
            Michael McCandless
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development