OTP tools like fprof refuse to profile your .so (for a good reason). So how to do this?
erl is like any other executable loads linked in driver as a shared library and one can intorspect this shared library like any other. During compilation one need to add debug info to .so file (-ggdb flag for gcc) then attach to running erlang virtual machine from gdb or kdbg or similar.
To profile do the following
In this particular example you can see cons (|) for list creation is really slow (procedure ei_x_encode_list_header). Knowing list size beforehand decreases caller relative execution time from 34.45% to 23.25%.
Note that profiling is not a sign of premature optimization but also a sanity check that you do not do some insane things.
erl is like any other executable loads linked in driver as a shared library and one can intorspect this shared library like any other. During compilation one need to add debug info to .so file (-ggdb flag for gcc) then attach to running erlang virtual machine from gdb or kdbg or similar.
> ps ax | grep erlang 9801 pts/1 Sl+ 0:00 /usr/lib64/erlang/erts-5.8.1/bin/beam.smp -K true -- -root /usr/lib64/erlang -progname erl -- -home /home/adolgarev -- 11208 pts/0 S+ 0:00 grep erlang > kdbg -p 9801 /usr/lib64/erlang/erts-5.8.1/bin/beam.smpNow breakpoints can be added and program state inspected
To profile do the following
valgrind --tool=callgrind --trace-children=yes /usr/bin/erlRun tests, grab callgrind.out.PID, open it in kcachegrind
In this particular example you can see cons (|) for list creation is really slow (procedure ei_x_encode_list_header). Knowing list size beforehand decreases caller relative execution time from 34.45% to 23.25%.
Note that profiling is not a sign of premature optimization but also a sanity check that you do not do some insane things.
No comments:
Post a Comment