Am I over-optimizing unchanged tuple results?

If I remember correctly both :ok idioms compile to the same bytecode and this has been true for a while now. Can’t remember since which OTP version though.

Either way fresh memory is not not allocated from for value. It just points to value object which was originally created in {:ok, value}.

{:ok, value} -> {:ok, value} 

both variables value will point to same value as the data has not changed. Only fresh tuple is created here is my understanding.

These small optimisations won’t result in much difference when compared to memory leaks and overflowing queues. I write code in a more readable way rather than worry about optimising. I believe in below quote

“Premature optimization is the root of all evil” - Donald Knuth

Everyday tooling is becoming intelligent and computing is becoming cheaper - so the optimisation for limited resource environments is not needed as of today is what I believe.

It’s the tuple creation that I’m concerned about. Sure, it’s cheap, but it’s not zero. Similarly, when I only care about what the shape of the {:ok, value} result is, I do this:

case something() do
  {:ok, value} -> # do something interesting with value
  error -> error
end

If the code generation for {:ok, value} -> {:ok, value} now avoids the creation of the second tuple (because it’s recognized as a duplicate), then the optimization is unnecessary. If it doesn’t, then I’d rather stick with the existing pattern, because I do have such things in tight loops where tuple creation might not be ideal

The opposite case of the error -> error shape above isn’t always possible:

case something() do
  {:ok, %{}} = ok -> ok # or {:ok, %{} = value} -> {:ok, value}
  {:ok, _} -> {:error, "Invalid return"}
  error -> error
end

You will find answer benchmarking your code using benchee or similar tool.

There are some pitfalls in testing individual scenarios unless some special algorithm is being benchmarked:

• optimising code which is not frequently called - like that part of code is never hotspot
• marginal memory improvements which don’t make much difference on production environments server which are never utilised full most of the time and anyways memory is reclaimed by garbage collection at some point.

My belief is true test for a project as whole is production deployment. If I find an issue in production I will profile and see why resource utilization is high - bottle neck in resources, code, etc.

Just to chime in: when this level of optimization is what you need, you might check out a different language or use something like rustler. After all: the mass result of this nano-optimization is thousand times gone as soon as you do something else slightly off.

I believe Core Erlang Optimizations - Erlang/OTP shows that it optimizes to zero in this case. It’ll just reuse the tuple whether you write it out that way or not.

You can also ditch the casealtogether and use with:

with {:error, reason} <- some_operation() do
  # do something with reason
end

Not sure if that will result in a more optimized code thought.

Thanks. This is exactly what I was looking for.

That will end up resulting in the same code, IIRC, since with is a macro and sugar for nested case expressions. In general, I only use with if:

1. I have more than one item that would require nested cases.
2. I have no or very little special handling of unsuccessful matches in with.

The moment that I need to treat non-ideal-path handling differently, the value of with drops immensely.

I feel jealous because I practically said the same thing but was utterly ignored.

Thanks for the link!