Inline some Process calls

[fishcakez]

Currently it is not possible to make use of a receive optimisation[1] without using :erlang.monitor/2 directly. The optimisation doesn't occur when using Process.monitor/1 because the call is not to :erlang.make_ref/1 or :erlang.monitor/2 directly.

Example:

defmodule RecvOpt do

  def bench() do
    :ok = setup()
    { elixir_time, :ok } = :timer.tc(&elixir_call/0)
    { erlang_time, :ok } = :timer.tc(&erlang_call/0)
    { elixir_time, erlang_time }
  end

  defp setup() do
    _ = Enum.each(1..1000000, fn(_) -> self() <- :hi end)
    :ok
  end

  defp elixir_call() do
    pid = Process.spawn(&target/0)
    selfie = self()
    ref = Process.monitor(pid)
    :erlang.send(pid, {:tag, {selfie, ref}, :hi})
    receive do
      {^ref, :hello} ->
        :ok
      {:"DOWN", ^ref, _, _, reason} ->
        reason
    end
  end

  defp erlang_call() do
    pid = Process.spawn(&target/0)
    selfie = self()
    ref = :erlang.monitor(:process, pid)
    :erlang.send(pid, {:tag, {selfie, ref}, :hi})
    receive do
      {^ref, :hello} ->
        :ok
      {:"DOWN", ^ref, _, _, reason} ->
        reason
    end
  end

  defp target() do
    receive do
      {:tag, {from, ref}, _} ->
        from <- {ref, :hello}
    end
  end

end

[1] http://erlang.org/pipermail/erlang-questions/2010-June/051751.html

[josevalim]

I think we should go ahead and inline almost all of Process. /cc @yrashk?

[ericmj]

Looks like this was accidentally closed.

[yrashk]

Great catch. I would agree on inlining Process.monitor (in fact, this is really necessary). @josevalim what is the motivation for inlining most of the module?

[josevalim]

So we get the same semantics as erlang everywhere. What else is erlang optimizing and we don't know?

[yrashk]

I see your point, although in this case you need to inline most of stdlib (how do you know it is not optimizing X.Y/Z?)

[josevalim]

@yrashk the minimum we can do is inline the :erlang module functions. I think at least the other ones can be tackled on a case by case basis.

[yrashk]

Agreed. Will this impact existing codebases (other than elixir its own) in any way? (well, besides the upside of getting better performance :) I suppose not.

[josevalim]

It depends. If we do the optimization in the compiler, nobody. But it means the code you see in Process is not actually invoked. If we do the optimization in the Process module, by making them macros, it means you can't invoke the Process stuff dynamically (like p = Process; p.some_fun).