инструменты производительности для Эрл

Question

При написании функции, как факториал:

fac(Val) when is_integer(Val)-> 
    Visit = fun (X, _F) when X < 2 -> 
        1; 
       (X, F) -> 
        X * F(X -1, F) 
      end, 
    Visit(Val, Visit). 

один не могу не заметить, что оптимизация хвост вызов не прямо вперед, однако писать его в продолжение стиля синтаксического анализа является:

fac_cps(Val) when is_integer(Val)-> 
    Visit = fun (X, _F, K) when X < 2 -> 
        K (1); 
       (X, F, K) -> 
        F(X-1, F, fun (Y) -> K(X * Y) end) 
      end, 
    Visit(Val, Visit, fun (X) -> X end). 

Или, возможно, даже defunctionalized:

fac_cps_def_lambdas({lam0}, X) -> 
    X; 
fac_cps_def_lambdas({lam1, X, K}, Y) -> 
    fac_cps_def_lambdas(K, X*Y). 


fac_cps_def(X) when is_integer(X) -> 
    fac_cps_def(X, {lam0}). 

fac_cps_def(X, K) when X < 2 -> 
    fac_cps_def_lambdas(K,1); 
fac_cps_def(X, K) -> 
    fac_cps_def(X-1, {lam1, X, K}). 

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

Мой вопрос в том, есть ли способ получить более подробные знания, чем это? Как я могу, например, получить использование памяти для выполнения функции - я вообще избегаю какой-либо памяти стека?

Что такое стандартные инструменты для проверки таких вещей?

Вопросы снова, как я могу определить высоту стека функций, как определить использование памяти для вызова функции на каждом из них и, наконец, какой из них лучше?

Answer 1

Мое решение - просто проверить код глазами. Со временем вы научитесь определять, находится ли код в стиле хвоста. Обычно, мне все равно, если я не знаю, насколько размер структуры, проходящей через этот код, будет огромным.

Это просто интуиция для меня. Вы можете проверить размер стека процесса с помощью erlang:process_info/2. Вы может проверить время выполнения с fprof. Но я делаю это только как последнее исправление.

Answer 2

Это не отвечает на ваш вопрос, но почему вы написали такой код? Это не очень Эрланги. Обычно вы не используете явный CPS, если для этого нет конкретной причины, обычно это не требуется.

Как @IGIVECRAPANSWERS говорит, что вы скоро научитесь видеть хвост-звонки, и Есть очень мало случаев, когда вы на самом деле ДОЛЖЕН использовать его.

EDIT: Комментарий к комментарию. Нет никакого прямого способа проверить, использовал ли компилятор LCO или нет. Он делает именно то, что вы рассказываете, и предполагает, что вы знаете, что делаете, и почему. :-) Тем не менее, вы можете быть уверены, что это происходит, когда это возможно, но что это так. Единственный способ проверить - посмотреть размер стека процесса, чтобы увидеть, растет ли он или нет. К сожалению, если вы ошибаетесь в правильном месте, процесс может расти очень медленно, и его трудно обнаружить, за исключением длительного периода времени.

Но снова очень мало мест, где вам действительно нужно получить LCO.

P.S. Вы используете термин LCO (Last Call Optimization), который я узнал раньше. Теперь, однако, «они», похоже, используют TCO (Tail Call Optimization). Это прогресс. :-)