I was able to use José and @BartOtten example to remove most of the guards I had in my lexer sql/lib/lexer.ex at main · elixir-dbvisor/sql · GitHub
guards is another issue for compilation and runtime performance. Highly recommend this approach if you’re doing performance work, guards is a big no no in that matter.
As I see it correctly you mean the Case-variant, no?
@josevalim thanks for the hd trick for quoted cases 
Had [unquote_splicing(clause_ast)] in the back of my head but that did not work in this case (so gave up an wrote pure AST). Using hd is tight. Barely an inconvenience.
I generally disagree with this conclusion but I am glad to be proven wrong if there are benchmarks proving so.
The issue in @BartOtten ‘s example was not the guards, simply the amount of code of generated. If you reduce the amount of code you generate, be it in the form of guards, function calls, data structures, it will likely speed up compiler and runtime. So there is a chance you are reducing the amount of guards, which leads to reduced lines of code, and that’s what is actually improving, it is not about the guards themselves.
Benchmarks are always tricky and it is very easy to take wrong conclusions.
This is true. I only tried to demonstrate that (macro generating) many function heads with the same guards could be optimized by wrapping unguarded case clauses in a single guarded function head. It’s simply less code/AST, less to check.
The reason why I called the case-variant “immune to adding guards”, is because the amount of guards does not multiply in that example, where in the head-example it does multiply by the amount of heads. It has nothing to do with the guard construct itself.
‘Bloated’ AST function heads
In this example the struct is repeated over and over.
def foo(%Struct{foo: "bar"}), do: :bartender
def foo(%Struct{foo: "zip"}), do: :zippy
def foo(%Struct{foo: "zelo"}), do: :zarika
(and then 1000 more)
Versus
Reduced AST case variant
There is less code as some constructs (def, struct) are not repeated a 1000 times.
def foo(%Struct{foo: my_var}) do
case my_var do
"bar" -> :bartender
"zip" -> :zippy
"zelo" -> :zarika
(and then 1000 more)
end
end
Reduced AST function heads
This also avoids repetition and has reduced AST.
def foo(%Struct{foo: my_var}), do: do_foo(my_var)
defp do_foo("bar"), do: :bartender
defp do_foo("zip"), do: :zippy
defp do_foo("zelo"), do: :zarika
(and then 1000 more)
This also goes for all other things where you can eliminate AST by simply writing/generating code differently.
I already posted a benchmark showcasing guards are roughly 2.5x slower then pattern matching Compiling files with many function heads is very slow(OTP 26 issue?) - #44 by Schultzer and here is the code Compiling files with many function heads is very slow(OTP 26 issue?) - #51 by Schultzer
I did not see code with no guards (you mentioned you did change, but no reproducible examples afaik) and the version you posted on the Erlang Forums simply added a body to the clause. No guards involved. And that case the difference in performance was related to the amount of generated code. We can continue the discussion here: Why does the efficiency guide not mention how expensive exported functions can be for compilation times - #22 by Schultzer - Questions / Help - Erlang Programming Language Forum - Erlang Forums
In any case, @BartOtten nailed the root cause in his last comment above.
The code I posted is benchmarking a function using case statement against a function using a guard. And pattern matching outperform guards.
The issue in the ErlangForum is about how to generate this case statement efficiently for the compiler when the return is a function call.
If that is because the guard function is using utf8 is beside the point as the way the function is written makes it slower by 2.5x
defmodule Test do
require Unicode.Set
case_ast =
for c <- Unicode.Set.to_pattern!("[[:Lu:], [:Ll:], [:Lt:], [:Lm:], [:Lo:], [:Nl:], [:Mn:], [:Mc:], [:Nd:], [:Pc:], [:Cf:]]") do
hd(
quote do
<<unquote(c), _::binary>> -> true
end
)
end ++ quote do
_ -> false
end
def case_fn(binary) do
case binary do
unquote(case_ast)
end end
def guard_fn(<<b::utf8, _::binary>>) when Unicode.Set.match?(b, "[[:Lu:], [:Ll:], [:Lt:], [:Lm:], [:Lo:], [:Nl:], [:Mn:], [:Mc:], [:Nd:], [:Pc:], [:Cf:]]"), do: true
def guard_fn(_binary), do: false
end
➜ sql git:(main) ✗ mix sql.bench
Operating System: macOS
CPU Information: Apple M1 Max
Number of Available Cores: 10
Available memory: 64 GB
Elixir 1.20.0-dev
Erlang 28.1
JIT enabled: true
Benchmark suite executing with the following configuration:
warmup: 2 s
time: 5 s
memory time: 2 s
reduction time: 2 s
parallel: 1
inputs: 1..100_000
Estimated total run time: 22 s
Measured function call overhead as: 0 ns
Benchmarking case with input 1..100_000 ...
Benchmarking guard with input 1..100_000 ...
Calculating statistics...
Formatting results...
##### With input 1..100_000 #####
Name ips average deviation median 99th %
case 15.07 M 66.35 ns ±42238.21% 42 ns 42 ns
guard 6.14 M 162.76 ns ±15740.33% 125 ns 167 ns
Comparison:
case 15.07 M
guard 6.14 M - 2.45x slower +96.41 ns
Memory usage statistics:
Name Memory usage
case 40 B
guard 40 B - 1.00x memory usage +0 B
**All measurements for memory usage were the same**
Reduction count statistics:
Name Reduction count
case 2
guard 2 - 1.00x reduction count +0
So this thread was missing the “single guarded delegating function” versus “single guarded function with unguarded case clauses” benchmark results. So for completeness:
OPTIMIZED MULTI HEAD: 3519.502 ms
defmodule Heads.A do
def foo(x,y) when is_integer(x) and is_integer(y), do: do_foo(x,y)
for i <- 1..10000 do
def do_foo(x = unquote(i), _y = unquote(i)), do: unquote(i)
end
end
Versus
OPTIMIZED CASE: 3527.108 ms
defmodule Case.A do
case_ast =
for i <- 1..10000 do
hd(
quote do
{x = unquote(i), _y = unquote(i)} -> unquote(i)
end
)
end
def foo(x, y) when is_integer(x) and is_integer(y) do
case {x, y} do
unquote(case_ast)
end
end
end
The compilation time difference is insignificant and switching in favor between the two methods. So you might think both are equal. Well, no…
Using HEAD you get 10000 reports that “variable x is unused” and should probably be underscored, while the unused variable is not detected when using CASE. If you care about clean code, the OPTIMIZED MULTI HEAD is the better option.
[1] disclaimer: in this case, don’t fall for premature optimization, always bench your own use case if you really want to know, unless José tells you otherwise
Footnotes ↩︎
These is alsno no difference between using a lot of def versus a lot of defp. These timings are for 50.000 (+1 public) heads.
test_defp.ex compiled in 14098.673 ms
test_def.ex compiled in 14061.436 ms