Valori di ritorno dalle funzioni quando l'efficienza conta

Question

Mi sembra che ci siano diversi modi per restituire un valore da una funzione di Bash.

Approccio 1: Utilizzare una variabile "locale-globale", che è definito come local nella chiamante:

func1() { 
    a=10 
} 

parent1() { 
    local a 

    func1 
    a=$(($a + 1)) 
} 

Approccio 2: comando Uso sostituzione:

func2() { 
    echo 10 
} 

parent2() { 
    a=$(func2) 
    a=$(($a + 1)) 
} 

Quanto ci si potrebbe aspettare dall'utilizzo dell'approccio 1 rispetto all'approccio 2?

E, so che non è buona pratica di programmazione utilizzare variabili globali come nell'approccio 1, ma a un certo punto potrebbe essere giustificato a causa di considerazioni sull'efficienza?

Answer 1

L'unica operazione più costosa nello scripting di shell è la biforcazione. Qualsiasi operazione che coinvolga una forcella, come la sostituzione di comando, sarà di 1-3 ordini di grandezza più lenta di una che non lo fa.

Ad esempio, ecco un approccio diretto per un ciclo che legge un gruppo di file generati sulla forma dei file-1234 e ne estrae il prefisso file- utilizzando sed, che richiede un totale di tre forcelle (sostituzione di comando + due stadi di canalizzazione) :

$ time printf "file-%s\n" {1..10000} | 
    while read line; do n=$(echo "$line" | sed -e "s/.*-//"); done 

real 0m46.847s 

Ecco un ciclo che fa la stessa cosa con l'espansione di parametro, che non richiede forcelle:

$ time printf "file-%s\n" {1..10000} | 
    while read line; do n=${line#*-}; done 

real 0m0.150s 

la versione Forky prende 300x più a lungo.

Pertanto, la risposta alla tua domanda è sì: se l'efficienza è importante, hai una solida giustificazione per il factoring o la sostituzione del codice di forky.

Quando il conteggio delle forche è costante rispetto all'ingresso (o è troppo disordinato per renderlo costante) e il codice è ancora troppo lento, è in quel momento che è necessario riscriverlo in una lingua più veloce.

Answer 2

sicuramente approccio 1 è molto più veloce di approccio 2 perché non ha alcun interrupt (che a sua volta potrebbe richiedere più kernel OS che attraversano per servizio) e ha solo un accesso alla memoria !!!