# Closure vs call overloading

**URL:** https://discourse.julialang.org/t/closure-vs-call-overloading/3240
**Category:** General Usage
**Tags:** closure
**Created:** [April 16, 2017, 5:21pm UTC](https://discourse.julialang.org/t/closure-vs-call-overloading/3240 "2017-04-16T17:21:15Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![matthieu](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@matthieu](https://discourse.julialang.org/u/matthieu)
#### Post date: [April 16, 2017, 5:21pm UTC](https://discourse.julialang.org/t/closure-vs-call-overloading/3240/1 "2017-04-16T17:21:15Z")

</div>

I have defined a function F that takes a function fas an argument (say F solves for x such that f(x) = 0). The function F calls the function f within large `for` loops etc.

I have noticed that there was a large difference in performances (3x) between having f, the first argument of F, as a closure VS a callable object. I thought that, in Julia 0.5, closures were as performant as callable objects. Unfortunately, I cannot find a simple example that reproduces the problem. I think the difference is due to the fact f is not inlined within a call F. Would someone know more? Is there a way to force inlining of f within `F`?

This code clarifies the two ways of defining `f`:

```julia
type Parameters
a::Float64
b::Float64
end
p = Parameters(10.0, 10.0)

# closure
function f(p::Parameters, x)
...
end
F(x -> f(p, x))

# call overloading
function (p::Parameters)(x)
... 
end
F(p)

```

Thanks

---

<div class="post-metadata">

### Author: ![fengyang.wang](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fengyang.wang/32/104_2.png) [@fengyang.wang](https://discourse.julialang.org/u/fengyang.wang)
#### Post date: [April 16, 2017, 5:26pm UTC](https://discourse.julialang.org/t/closure-vs-call-overloading/3240/2 "2017-04-16T17:26:08Z")

</div>

It looks like you are using global variables. If you make `p` const, or wrap everything in a function, then they should be equally performant.
