Kiedy należy używać strumieni?

Właśnie natknąłem się na pytanie, kiedy używam a Listi jego stream()metody. Chociaż wiem, jak ich używać, nie jestem pewien, kiedy ich używać.

Na przykład mam listę zawierającą różne ścieżki do różnych lokalizacji. Teraz chciałbym sprawdzić, czy pojedyncza podana ścieżka zawiera którąkolwiek ze ścieżek określonych na liście. Chciałbym zwrócićboolean podstawie tego, czy warunek został spełniony.

Oczywiście nie jest to trudne zadanie samo w sobie. Ale zastanawiam się, czy powinienem używać strumieni, czy pętli for (-each).

Lista

private static final List<String> EXCLUDE_PATHS = Arrays.asList(new String[]{
    "my/path/one",
    "my/path/two"
});

Przykład - Stream

private boolean isExcluded(String path){
    return EXCLUDE_PATHS.stream()
                        .map(String::toLowerCase)
                        .filter(path::contains)
                        .collect(Collectors.toList())
                        .size() > 0;
}

Przykład - pętla For-Each

private boolean isExcluded(String path){
    for (String excludePath : EXCLUDE_PATHS) {
        if(path.contains(excludePath.toLowerCase())){
            return true;
        }
    }
    return false;
}

Zwróć uwagę, że pathparametr jest zawsze pisany małymi literami .

Moje pierwsze przypuszczenie jest takie, że podejście for-each jest szybsze, ponieważ pętla powróci natychmiast, jeśli warunek zostanie spełniony. Podczas gdy strumień nadal będzie przechodził przez wszystkie wpisy na liście, aby zakończyć filtrowanie.

Czy moje założenie jest prawidłowe? Jeśli tak, dlaczego (a raczej kiedy ) miałbym stream()wtedy użyć ?

Twoje założenie jest poprawne. Twoja implementacja strumienia jest wolniejsza niż pętla for.

To użycie strumienia powinno być jednak tak szybkie jak pętla for:

EXCLUDE_PATHS.stream()  
                               .map(String::toLowerCase)
                               .anyMatch(path::contains);

Powoduje to iterację przez elementy, stosowanie String::toLowerCasei filtrowanie elementów jeden po drugim i kończenie na pierwszym elemencie pasującym .

Obie collect()& anyMatch()są operacjami terminalowymi. anyMatch()wychodzi jednak przy pierwszym znalezionym elemencie, podczas gdy collect()wymaga przetworzenia wszystkich elementów.

Decyzja, czy użyć strumieni, czy nie, nie powinna być podyktowana rozważaniami dotyczącymi wydajności, ale raczej czytelnością. Jeśli chodzi o wydajność, należy wziąć pod uwagę inne kwestie.

Swoim .filter(path::contains).collect(Collectors.toList()).size() > 0podejściem przetwarzasz wszystkie elementy i zbierasz je w tymczasoweList , zanim porównasz rozmiar, jednak rzadko ma to znaczenie dla strumienia składającego się z dwóch elementów.

Używanie .map(String::toLowerCase).anyMatch(path::contains)może zaoszczędzić cykle procesora i pamięć, jeśli masz znacznie większą liczbę elementów. Mimo to konwertuje to każdą Stringna reprezentację małych liter, dopóki nie zostanie znalezione dopasowanie. Oczywiście jest sens używania

private static final List<String> EXCLUDE_PATHS =
    Stream.of("my/path/one", "my/path/two").map(String::toLowerCase)
          .collect(Collectors.toList());

private boolean isExcluded(String path) {
    return EXCLUDE_PATHS.stream().anyMatch(path::contains);
}

zamiast. Nie musisz więc powtarzać konwersji na małe litery przy każdym wywołaniu isExcluded. Jeśli liczba elementów EXCLUDE_PATHSlub długości ciągów stają się naprawdę duże, możesz rozważyć użycie

private static final List<Predicate<String>> EXCLUDE_PATHS =
    Stream.of("my/path/one", "my/path/two").map(String::toLowerCase)
          .map(s -> Pattern.compile(s, Pattern.LITERAL).asPredicate())
          .collect(Collectors.toList());

private boolean isExcluded(String path){
    return EXCLUDE_PATHS.stream().anyMatch(p -> p.test(path));
}

Skompilowanie łańcucha jako wzorca wyrażenia regularnego z LITERALflagą sprawia, że ​​zachowuje się on jak zwykłe operacje na łańcuchach, ale pozwala silnikowi spędzić trochę czasu na przygotowaniach, np. Przy użyciu algorytmu Boyera Moore'a, aby być bardziej wydajnym, jeśli chodzi o faktyczne porównanie.

Oczywiście opłaca się to tylko wtedy, gdy jest wystarczająco dużo kolejnych testów, aby zrekompensować czas spędzony na przygotowaniach. Ustalenie, czy tak się stanie, jest jednym z faktycznych rozważań dotyczących wydajności, poza pierwszym pytaniem, czy ta operacja kiedykolwiek będzie miała krytyczne znaczenie dla wydajności. Nie chodzi o to, czy używać strumieni, czyfor pętli.

Nawiasem mówiąc, powyższe przykłady kodu zachowują logikę oryginalnego kodu, który wydaje mi się wątpliwy. Twoja isExcludedmetoda zwraca true, jeśli określona ścieżka zawiera którykolwiek z elementów na liście, więc wraca truedla /some/prefix/to/my/path/one, a także my/path/one/and/some/suffixlub nawet /some/prefix/to/my/path/one/and/some/suffix.

Nawet dummy/path/onerousjest uważany za spełniający kryteria, ponieważ jest containsciągiem my/path/one…

Tak. Masz rację. Twoje podejście do transmisji będzie miało pewne obciążenie. Ale możesz użyć takiej konstrukcji:

private boolean isExcluded(String path) {
    return  EXCLUDE_PATHS.stream().map(String::toLowerCase).anyMatch(path::contains);
}

Głównym powodem korzystania ze strumieni jest to, że sprawiają, że kod jest prostszy i łatwiejszy do odczytania.

Celem strumieni w Javie jest uproszczenie pisania kodu równoległego. Inspiruje się programowaniem funkcjonalnym. Strumień szeregowy służy tylko do czyszczenia kodu.

Jeśli zależy nam na wydajności, powinniśmy użyć parallelStream, do którego został zaprojektowany. Szeregowy jest generalnie wolniejszy.

Jest dobry artykuł czytać o , a wydajność ForLoopStreamParallelStream .

W Twoim kodzie możemy użyć metod zakończenia, aby zatrzymać wyszukiwanie na pierwszym dopasowaniu. (anyMatch ...)

Jak inni wspominali o wielu dobrych punktach, ale ja chcę tylko wspomnieć o leniwej ocenie w ocenie strumienia. Kiedy map()tworzymy strumień ścieżek z małymi literami, nie tworzymy od razu całego strumienia, zamiast tego strumień jest konstruowany leniwie , dlatego wydajność powinna być równoważna tradycyjnej pętli for. Nie wykonuje pełnego skanowania map()i anyMatch()jest wykonywany w tym samym czasie. Gdy anyMatch()zwróci prawdę, nastąpi zwarcie.