# `mix profile.eprof` [🔗](https://github.com/elixir-lang/elixir/blob/v1.20.1/lib/mix/lib/mix/tasks/profile.eprof.ex#L5) Profiles the given file or expression using Erlang's `eprof` tool. [`:eprof`](`:eprof`) provides time information of each function call and can be useful when you want to discover the bottlenecks related to this. Before running the code, it invokes the `app.start` task which compiles and loads your project. After that, the target expression is profiled together with all matching function calls using the Erlang trace BIFs. The tracing of the function calls for that is enabled when the profiling is begun, and disabled when profiling is stopped. To profile the code, you can use syntax similar to the `mix run` task: $ mix profile.eprof -e Hello.world $ mix profile.eprof -e "[1, 2, 3] |> Enum.reverse |> Enum.map(&Integer.to_string/1)" $ mix profile.eprof my_script.exs arg1 arg2 arg3 This task is automatically re-enabled, so you can profile multiple times in the same Mix invocation. ## Command line options * `--matching` - only profile calls matching the given `Module.function/arity` pattern * `--calls` - filters out any results with a call count lower than this * `--time` - filters out any results that took lower than specified (in µs) * `--sort` - sorts the results by `time` or `calls` (default: `time`) * `--eval`, `-e` - evaluates the given code * `--require`, `-r` - requires pattern before running the command * `--parallel`, `-p` - makes all requires parallel * `--no-warmup` - skips the warmup step before profiling * `--no-compile` - does not compile even if files require compilation * `--no-deps-check` - does not check dependencies * `--no-archives-check` - does not check archives * `--no-halt` - does not halt the system after running the command * `--no-start` - does not start applications after compilation * `--no-elixir-version-check` - does not check the Elixir version from mix.exs ## Profile output Example output: # CALLS % TIME µS/CALL Total 24 100.0 26 1.08 Enum.reduce_range_inc/4 5 3.85 1 0.20 :erlang.make_fun/3 1 7.69 2 2.00 Enum.each/2 1 7.69 2 2.00 anonymous fn/0 in :elixir_compiler_0.__FILE__/1 1 7.69 2 2.00 :erlang.integer_to_binary/1 5 15.39 4 0.80 :erlang.apply/2 1 15.39 4 4.00 anonymous fn/3 in Enum.each/2 5 19.23 5 1.00 String.Chars.Integer.to_string/1 5 23.08 6 1.20 Profile done over 8 matching functions The default output contains data gathered from all matching functions. The first row after the header contains the sums of the partial results and the average time for all the function calls listed. The following rows contain the function call, followed by the number of times that the function was called, then by the percentage of time that the call uses, then the total time for that function in microseconds, and, finally, the average time per call in microseconds. When `--matching` option is specified, call count tracing will be started only for the functions matching the given pattern: # CALLS % TIME µS/CALL Total 5 100.0 6 1.20 String.Chars.Integer.to_string/1 5 100.0 6 1.20 Profile done over 1 matching functions The pattern can be a module name, such as `String` to count all calls to that module, a call without arity, such as `String.split`, to count all calls to that function regardless of arity, or a call with arity, such as `String.split/3`, to count all calls to that exact module, function and arity. ## Caveats You should be aware that the code being profiled is running in an anonymous function which is invoked by [`:eprof` module](`:eprof`). Thus, you'll see some additional entries in your profile output. It is also important to note that the profiler is stopped as soon as the code has finished running, and this may need special attention, when: running asynchronous code as function calls which were called before the profiler stopped will not be counted; running synchronous code as long running computations and a profiler without a proper MFA trace pattern or filter may lead to a result set which is difficult to comprehend. You should expect a slowdown in your code execution using this tool since `:eprof` has some performance impact on the execution, but the impact is considerably lower than `Mix.Tasks.Profile.Fprof`. If you have a large system try to profile a limited scenario or focus on the main modules or processes. Another alternative is to use `Mix.Tasks.Profile.Cprof` that uses [`:cprof`](`:cprof`) and has a low performance degradation effect. # `profile_opts` ```elixir @type profile_opts() :: [ matching: {module() | :_, atom() | :_, arity() | :_}, calls: non_neg_integer(), time: non_neg_integer(), sort: :time | :calls, warmup: boolean(), set_on_spawn: boolean() ] ``` Options for the eprof profiler. # `profile` ```elixir @spec profile((-> result), profile_opts()) :: result when result: any() ``` Allows to programmatically run the `eprof` profiler on expression in `fun`. Returns the return value of `fun`. ## Options * `:matching` - only profile calls matching the given pattern in form of `{module, function, arity}`, where each element may be replaced by `:_` to allow any value * `:calls` - filters out any results with a call count lower than this * `:time` - filters out any results that took lower than specified (in µs) * `:sort` - sort the results by `:time` or `:calls` (default: `:time`) * `:warmup` - if the code should be warmed up before profiling (default: `true`) * `:set_on_spawn` - if newly spawned processes should be measured (default: `true`) --- *Consult [api-reference.md](api-reference.md) for complete listing*