Quando dovrei usare gli stream?

Ho appena trovato una domanda durante l'utilizzo di a Liste il suo stream()metodo. Anche se so come usarli, non sono abbastanza sicuro di quando usarli.

Ad esempio, ho un elenco, contenente vari percorsi verso posizioni diverse. Ora, vorrei verificare se un singolo percorso specificato contiene uno dei percorsi specificati nell'elenco. Vorrei restituire un in booleanbase al fatto che la condizione sia stata soddisfatta o meno.

Questo ovviamente non è un compito difficile di per sé. Ma mi chiedo se dovrei usare flussi o un ciclo for (-each).

La lista

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

Esempio: Stream

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

Esempio: ciclo For-Each

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

Notare che il pathparametro è sempre minuscolo .

La mia prima ipotesi è che l'approccio for-each sia più veloce, perché il ciclo tornerebbe immediatamente, se la condizione è soddisfatta. Mentre il flusso continua a scorrere tutte le voci dell'elenco per completare il filtraggio.

La mia ipotesi è corretta? Se è così, perché (o meglio quando ) dovrei usare stream()allora?

La tua ipotesi è corretta. L'implementazione del tuo flusso è più lenta del ciclo for.

Questo utilizzo del flusso dovrebbe essere veloce quanto il ciclo for:

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

Questo itera attraverso gli elementi, applicando String::toLowerCasee il filtro agli elementi uno per uno e terminando al primo elemento che corrisponde.

Entrambe collect()& anyMatch()sono operazioni del terminale. anyMatch()esce dal primo elemento trovato, tuttavia, collect()richiede l'elaborazione di tutti gli elementi.

La decisione se utilizzare Streams o meno non dovrebbe essere guidata dalla considerazione delle prestazioni, ma piuttosto dalla leggibilità. Quando si tratta davvero di prestazioni, ci sono altre considerazioni.

Con il tuo .filter(path::contains).collect(Collectors.toList()).size() > 0approccio, stai elaborando tutti gli elementi e raccogliendoli in modo temporaneo List, prima di confrontare le dimensioni, tuttavia, questo non importa quasi mai per uno Stream composto da due elementi.

L'utilizzo .map(String::toLowerCase).anyMatch(path::contains)può far risparmiare cicli di CPU e memoria, se si dispone di un numero sostanzialmente maggiore di elementi. Tuttavia, questo converte ciascuno Stringnella sua rappresentazione minuscola, finché non viene trovata una corrispondenza. Ovviamente, ha senso usare

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);
}

anziché. Quindi non è necessario ripetere la conversione in minuscolo in ogni chiamata di isExcluded. Se il numero di elementi EXCLUDE_PATHSo la lunghezza delle stringhe diventa molto grande, potresti prendere in considerazione l'utilizzo di

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));
}

Compilare una stringa come pattern regex con il LITERALflag, fa sì che si comporti come le normali operazioni sulle stringhe, ma consente al motore di dedicare un po 'di tempo alla preparazione, ad esempio utilizzando l'algoritmo di Boyer Moore, per essere più efficiente quando si tratta del confronto effettivo.

Naturalmente, questo ripaga solo se ci sono abbastanza test successivi per compensare il tempo speso nella preparazione. Determinare se questo sarà il caso, è una delle considerazioni sulle prestazioni effettive, oltre alla prima domanda se questa operazione sarà mai critica per le prestazioni. Non la questione se utilizzare Stream o forloop.

A proposito, gli esempi di codice sopra mantengono la logica del tuo codice originale, che mi sembra discutibile. Il tuo isExcludedmetodo restituisce true, se il percorso specificato contiene uno qualsiasi degli elementi nell'elenco, quindi restituisce trueper /some/prefix/to/my/path/one, così come my/path/one/and/some/suffixo anche /some/prefix/to/my/path/one/and/some/suffix.

Anche dummy/path/onerousè considerato soddisfare i criteri in quanto containsla stringa my/path/one...

Si. Hai ragione. Il tuo approccio allo streaming avrà un sovraccarico. Ma puoi usare una tale costruzione:

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

Il motivo principale per utilizzare i flussi è che rendono il codice più semplice e facile da leggere.

L'obiettivo dei flussi in Java è semplificare la complessità della scrittura di codice parallelo. È ispirato alla programmazione funzionale. Il flusso seriale serve solo a rendere il codice più pulito.

Se vogliamo prestazioni dovremmo usare parallelStream, che è stato progettato per. Quello seriale, in generale, è più lento.

C'è un buon articolo di leggere su , e prestazioni . ForLoopStreamParallelStream

Nel tuo codice possiamo utilizzare metodi di terminazione per interrompere la ricerca alla prima corrispondenza. (anyMatch ...)

Come altri hanno già menzionato molti punti positivi, voglio solo menzionare la valutazione pigra nella valutazione del flusso. Quando map()creiamo un flusso di percorsi minuscoli, non creiamo immediatamente l'intero flusso, invece il flusso è costruito pigramente , motivo per cui le prestazioni dovrebbero essere equivalenti al tradizionale ciclo for. Non sta eseguendo una scansione completa map()e anyMatch()vengono eseguiti allo stesso tempo. Una volta anyMatch()restituito vero, verrà cortocircuitato.