Erlang "catch" ekspresji vs try/catch pod względem wydajności

Question

Podobne pytanie zostało zadane na ten temat, ale nie zostało dokładnie zadane w tych samych warunkach.

Próbuję bezpiecznie odszyfrować pliki binarne base64, w kontekście, w którym jest to możliwe, dane wejściowe nie będą kodowane binarnie, a nawet kodowane base64.

Erlang mówi, niech to się zepsuje i poradzi sobie z tym - jeśli mam to zrobić, jaki jest najbardziej efektywny sposób. Wydajność jest bardzo ważna w tym systemie.

Wiem, aby uniknąć try/catch, ponieważ tworzy on pełną ścieżkę śledzenia - jednak czy słowo kluczowe catch jest sensowne w tym kontekście? Czy słowo kluczowe "catch" jest szybsze/wydajniejsze?

W funkcji takich jak

safe_decode(Binary) -> 
    case catch base64:decode(Binary) of 
     <<Result/binary>> -> {ok, Result}; 
     {'EXIT', _} -> {not_base64, Binary} 
    end. 

Czy to naprawdę bardziej wydajny niż połowu spróbować? Jak najlepiej poradzić sobie z tym scenariuszem w systemie, w którym ważna jest wydajność, tj. Awarie, które wymagają budowania śladu stosu i/lub wymagają więcej przetwarzania niż szczęśliwą ścieżkę należy traktować tak wydajnie, jak to możliwe.

Po prostu uczę się erlangu, więc może odpowiedź jest na mnie zwrócona.

Answer 1

Nie, odwrotnie: unikaj catch, ponieważ zawsze buduje ślad stosu. try + catch buduje tylko ślad stosu, jeśli poprosisz o to przy pomocy erlang:get_stacktrace().

Zapoznaj się z artykułem Heads-up: The cost of get_stacktrace(), zamieszczonym na stronie Erlanga przez Richarda Carlssona w dniu 2013-11-05. Podam kilka części:

(Streszczenie: wyjątki tanie, ale Erlang: get_stacktrace() rodzaj drogie; również unikać pytań expr '.)

Oczywiście nadal można wywołać metodę get_stacktrace() w wielu sytuacjach, np. np. gdy proces jest w drodze do poddania się lub zapisania informacji o awarii w dzienniku lub w przypadku czegoś, co zdarza się rzadko, i użyteczne są informacje śledzenia stosu - ale nigdy w funkcji bibliotecznej, która może być używana w znacznym stopniu. w pętli.

Wreszcie, jest to również kolejny powód do przerobienia starych wystąpienia pytań wyrażenie 'do 'spróbować wyrażenie złapać ... end'[...]