Вложенные циклы Java 8 с потоками и производительностью

Я создал быстрый и грязный микротест на основе вашего кода. Результаты:

контур: 3192
лямбда: 3140
лямбда параллельно: 868

Таким образом, цикл и лямбда эквивалентны, а параллельный поток значительно повышает производительность. Я подозреваю, что ваши результаты ненадежны из-за вашей методологии сравнительного анализа.

public static void main(String[] args) {
    int sum = 0;

    //warmup
    for (int i = 0; i < 100; i++) {
        solve();
        solveLambda();
        solveLambdaParallel();
    }

    {
        long start = System.nanoTime();
        for (int i = 0; i < 100; i++) {
            sum += solve();
        }
        long end = System.nanoTime();
        System.out.println("loop: " + (end - start) / 1_000_000);
    }
    {
        long start = System.nanoTime();
        for (int i = 0; i < 100; i++) {
            sum += solveLambda();
        }
        long end = System.nanoTime();
        System.out.println("lambda: " + (end - start) / 1_000_000);
    }
    {
        long start = System.nanoTime();
        for (int i = 0; i < 100; i++) {
            sum += solveLambdaParallel();
        }
        long end = System.nanoTime();
        System.out.println("lambda parallel : " + (end - start) / 1_000_000);
    }
    System.out.println(sum);
}

public static int digitSum(BigInteger x) {
    int sum = 0;
    for (char c : x.toString().toCharArray()) {
        sum += Integer.valueOf(c + "");
    }
    return sum;
}

public static int solve() {
    int max = 0;
    for (int i = 1; i < 100; i++) {
        for (int j = 1; j < 100; j++) {
            max = Math.max(max, digitSum(BigInteger.valueOf(i).pow(j)));
        }
    }
    return max;
}

public static int solveLambda() {
    return  IntStream.range(1, 100)
            .map(i -> IntStream.range(1, 100).map(j -> digitSum(BigInteger.valueOf(i).pow(j))).max().getAsInt())
            .max().getAsInt();
}

public static int solveLambdaParallel() {
    return  IntStream.range(1, 100)
            .parallel()
            .map(i -> IntStream.range(1, 100).map(j -> digitSum(BigInteger.valueOf(i).pow(j))).max().getAsInt())
            .max().getAsInt();
}

Я также запускал его с помощью jmh, который более надежен, чем ручные тесты. Результаты согласуются с приведенными выше (микросекунды на вызов):

Benchmark                                Mode   Mean        Units
c.a.p.SO21968918.solve                   avgt   32367.592   us/op
c.a.p.SO21968918.solveLambda             avgt   31423.123   us/op
c.a.p.SO21968918.solveLambdaParallel     avgt   8125.600    us/op

Проблема в том, что вы смотрите на неоптимальный код. Когда у вас есть код, который может быть сильно оптимизирован, вы очень зависите от того, достаточно ли умна JVM для оптимизации вашего кода. Петли существуют намного дольше и лучше понятны.

Одно большое отличие в вашем циклическом коде заключается в том, что ваш рабочий набор очень мал. Вы рассматриваете только одну максимальную сумму цифр за раз. Это означает, что код является дружественным к кэшу, и у вас есть очень недолговечные объекты. В случае с stream() вы создаете коллекции, для которых в любой момент времени больше рабочего набора, используя больше кеша, с большими накладными расходами. Я ожидаю, что ваше время GC будет больше и/или чаще.

почему потоковый вариант намного медленнее старого?

Циклы довольно хорошо оптимизированы, поскольку существовали еще до разработки Java. Они могут быть очень эффективно сопоставлены с оборудованием. Потоки довольно новые и не так сильно оптимизированы.

почему оператор parallel() на самом деле увеличил время с 0,19 до 0,25 с?

Скорее всего у вас узкое место на общем ресурсе. Вы создаете довольно много мусора, но обычно это довольно параллельно. Использование большего количества потоков только гарантирует, что у вас будет больше накладных расходов, но не гарантирует, что вы сможете воспользоваться дополнительной мощностью ЦП, которая у вас есть.