# Semantically equivalent expressions with wildly different performance

**URL:** <https://discourse.julialang.org/t/semantically-equivalent-expressions-with-wildly-different-performance/131123>\
**Category:** General Usage\
**Tags:** macros, broadcasting, wat\
**Created:** [July 28, 2025, 4:40am UTC](https://discourse.julialang.org/t/semantically-equivalent-expressions-with-wildly-different-performance/131123 "2025-07-28T04:40:52Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [July 28, 2025, 5:44am UTC](https://discourse.julialang.org/t/semantically-equivalent-expressions-with-wildly-different-performance/131123/4 "2025-07-28T05:44:09Z")

</div>

Yeah it basically ran faster because it didn’t do anything:

```julia-auto
julia> outer1!(copy(M), x, y) ≈ M
true

julia> M ≈ outer2!(copy(M), x, y)
false

```

Looks like `@.` failure causing a _method_ expression. This example of overlapping syntax causing a silent error probably counts as a [WAT](https://discourse.julialang.org/t/a-most-harrowing-collection-of-julia-wats/77323), so I suggest adding a #wat tag for future discoverability.

```julia-auto
julia> @macroexpand @. (view(output, :, j)) = x * y[j]
:(view(output, :, j) = begin
          #= REPL[51]:1 =#
          (*).(x, y[j])
      end)

julia> let
       view(output, :, j) = begin
               #= REPL[51]:1 =#
               (*).(x, y[j])
           end
       end
(::var"#view#3") (generic function with 1 method)

julia> @macroexpand @. (v) = x * y[j]
:(v .= (*).(x, y[j]))

julia> @macroexpand (view(output, :, j)) .= x .* y[j] # manual fix
:(view(output, :, j) .= x .* y[j])

```

A fix after which:

```julia-auto
julia> outer1!(copy(M), x, y) ≈ outer2!(copy(M), x, y)
true

julia> @btime outer1!($(copy(M)), $x, $y);
  248.700 μs (0 allocations: 0 bytes)

julia> @btime outer2!($(copy(M)), $x, $y);
  249.000 μs (0 allocations: 0 bytes)

```

Benchmarks that mutate their inputs are generally bad but this might be fine for runtime because there are no conditionals.

---

_[View the full topic](https://discourse.julialang.org/t/semantically-equivalent-expressions-with-wildly-different-performance/131123)._
