Java 8流:多个过滤器与复杂条件


235

有时您想过滤Stream具有多个条件的a:

myList.stream().filter(x -> x.size() > 10).filter(x -> x.isCool()) ...

或者你可以做同样的复杂条件和 filter

myList.stream().filter(x -> x.size() > 10 && x -> x.isCool()) ...

我的猜测是第二种方法具有更好的性能特征,但我不知道

第一种方法赢得了可读性,但是哪种性能更好?


57
编写在这种情况下可读性更高的代码。性能差异是最小的(并且高度情况下)。
Brian Goetz 2014年

5
忘记纳米优化,而使用高度可读和可维护的代码。对于流,应该始终单独使用每个操作,包括过滤器。
暗黑破坏神

Answers:


151

这两种选择都必须执行的代码是如此相似,以致您无法可靠地预测结果。基础对象结构可能有所不同,但这对热点优化器没有挑战。因此,如果有任何差异,则取决于其他周围条件,这些条件将导致更快的执行速度。

组合两个过滤器实例将创建更多的对象,从而创建更多的委托代码,但是如果您使用方法引用而不是lambda表达式(例如,替换filter(x -> x.isCool())为),则可以更改这种情况filter(ItemType::isCool)。这样,您就消除了为lambda表达式创建的综合委托方法。因此,与filter使用带有的lambda表达式的单个调用相比,使用两个方法引用组合两个过滤器可能会创建相同或更少的委托代码&&

但是,如上所述,这种开销将由HotSpot优化器消除,并且可以忽略不计。

从理论上讲,两个过滤器比单个过滤器更容易并行化,但这仅与计算量大的任务有关¹。

因此,没有简单的答案。

最重要的是,不要考虑气味检测阈值以下的性能差异。使用更具可读性的内容。


¹…并且将需要一个实现对后续阶段进行并行处理的实现,而标准Stream实现目前还没有采用


4
代码不是必须在每个过滤器之后迭代结果流吗?
jucardi

13
@胡安·卡洛斯·迪亚兹(Juan Carlos Diaz):不,信息流不会那样工作。阅读有关“惰性评估”的信息;中间操作不执行任何操作,它们只会更改最终操作的结果。
Holger

34

从性能的角度来看,复杂的过滤条件会更好,但是最好的性能将显示使用标准循环的老式方法if clause是最好的选择。小阵列上的差异为10个元素,差异可能约为2倍,大阵列上的差异不是那么大。
您可以看一下我的GitHub项目,其中我对多个数组迭代选项进行了性能测试。

对于小型阵列10个元素吞吐量ops / s: 10元素数组 对于中型10,000个元素吞吐量ops / s: 在此处输入图片说明 对于大型阵列1,000,000个元素吞吐量ops / s: 1M元素

注意:测试在

  • 8个CPU
  • 1 GB内存
  • 操作系统版本:16.04.1 LTS(Xenial Xerus)
  • Java版本:1.8.0_121
  • 的JVM:-XX:+ UseG1GC-服务器-Xmx1024m -Xms1024m

更新: Java 11在性能方面取得了一些进步,但动态特性保持不变

基准测试模式:吞吐量,运营/时间 Java 8VS11


22

此测试表明,您的第二个选项可以表现得更好。首先是发现,然后是代码:

one filter with predicate of form u -> exp1 && exp2, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=4142, min=29, average=41.420000, max=82}
two filters with predicates of form u -> exp1, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=13315, min=117, average=133.150000, max=153}
one filter with predicate of form predOne.and(pred2), list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=10320, min=82, average=103.200000, max=127}

现在的代码:

enum Gender {
    FEMALE,
    MALE
}

static class User {
    Gender gender;
    int age;

    public User(Gender gender, int age){
        this.gender = gender;
        this.age = age;
    }

    public Gender getGender() {
        return gender;
    }

    public void setGender(Gender gender) {
        this.gender = gender;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }
}

static long test1(List<User> users){
    long time1 = System.currentTimeMillis();
    users.stream()
            .filter((u) -> u.getGender() == Gender.FEMALE && u.getAge() % 2 == 0)
            .allMatch(u -> true);                   // least overhead terminal function I can think of
    long time2 = System.currentTimeMillis();
    return time2 - time1;
}

static long test2(List<User> users){
    long time1 = System.currentTimeMillis();
    users.stream()
            .filter(u -> u.getGender() == Gender.FEMALE)
            .filter(u -> u.getAge() % 2 == 0)
            .allMatch(u -> true);                   // least overhead terminal function I can think of
    long time2 = System.currentTimeMillis();
    return time2 - time1;
}

static long test3(List<User> users){
    long time1 = System.currentTimeMillis();
    users.stream()
            .filter(((Predicate<User>) u -> u.getGender() == Gender.FEMALE).and(u -> u.getAge() % 2 == 0))
            .allMatch(u -> true);                   // least overhead terminal function I can think of
    long time2 = System.currentTimeMillis();
    return time2 - time1;
}

public static void main(String... args) {
    int size = 10000000;
    List<User> users =
    IntStream.range(0,size)
            .mapToObj(i -> i % 2 == 0 ? new User(Gender.MALE, i % 100) : new User(Gender.FEMALE, i % 100))
            .collect(Collectors.toCollection(()->new ArrayList<>(size)));
    repeat("one filter with predicate of form u -> exp1 && exp2", users, Temp::test1, 100);
    repeat("two filters with predicates of form u -> exp1", users, Temp::test2, 100);
    repeat("one filter with predicate of form predOne.and(pred2)", users, Temp::test3, 100);
}

private static void repeat(String name, List<User> users, ToLongFunction<List<User>> test, int iterations) {
    System.out.println(name + ", list size " + users.size() + ", averaged over " + iterations + " runs: " + IntStream.range(0, iterations)
            .mapToLong(i -> test.applyAsLong(users))
            .summaryStatistics());
}

3
有趣的是-当我更改在test1之前运行test2的顺序时,test1的运行速度稍慢。只有当test1第一次运行时,它才看起来更快。任何人都可以复制或有任何见解?
Sperr

5
这可能是因为HotSpot编译的成本是由首先运行的任何测试引起的。
DaBlick

@Sperr是对的,当顺序更改时,结果是不可预测的。但是,当我使用三个不同的线程运行此线程时,无论哪个线程首先启动,始终使用复杂的过滤器可以获得更好的结果。以下是结果。Test #1: {count=100, sum=7207, min=65, average=72.070000, max=91} Test #3: {count=100, sum=7959, min=72, average=79.590000, max=97} Test #2: {count=100, sum=8869, min=79, average=88.690000, max=110}
Paramesh Korrakuti

2

这是@Hank D共享的6个不同的样本测试组合的结果。很明显,u -> exp1 && exp2在所有情况下,形式谓词都是高性能的。

one filter with predicate of form u -> exp1 && exp2, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=3372, min=31, average=33.720000, max=47}
two filters with predicates of form u -> exp1, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=9150, min=85, average=91.500000, max=118}
one filter with predicate of form predOne.and(pred2), list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=9046, min=81, average=90.460000, max=150}

one filter with predicate of form u -> exp1 && exp2, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=8336, min=77, average=83.360000, max=189}
one filter with predicate of form predOne.and(pred2), list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=9094, min=84, average=90.940000, max=176}
two filters with predicates of form u -> exp1, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=10501, min=99, average=105.010000, max=136}

two filters with predicates of form u -> exp1, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=11117, min=98, average=111.170000, max=238}
one filter with predicate of form u -> exp1 && exp2, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=8346, min=77, average=83.460000, max=113}
one filter with predicate of form predOne.and(pred2), list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=9089, min=81, average=90.890000, max=137}

two filters with predicates of form u -> exp1, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=10434, min=98, average=104.340000, max=132}
one filter with predicate of form predOne.and(pred2), list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=9113, min=81, average=91.130000, max=179}
one filter with predicate of form u -> exp1 && exp2, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=8258, min=77, average=82.580000, max=100}

one filter with predicate of form predOne.and(pred2), list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=9131, min=81, average=91.310000, max=139}
two filters with predicates of form u -> exp1, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=10265, min=97, average=102.650000, max=131}
one filter with predicate of form u -> exp1 && exp2, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=8442, min=77, average=84.420000, max=156}

one filter with predicate of form predOne.and(pred2), list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=8553, min=81, average=85.530000, max=125}
one filter with predicate of form u -> exp1 && exp2, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=8219, min=77, average=82.190000, max=142}
two filters with predicates of form u -> exp1, list size 10000000, averaged over 100 runs: LongSummaryStatistics{count=100, sum=10305, min=97, average=103.050000, max=132}
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.