# Recursive inner functions a thousand times slower?

**URL:** https://discourse.julialang.org/t/recursive-inner-functions-a-thousand-times-slower/85604
**Category:** Performance
**Created:** [August 11, 2022, 4:43am UTC](https://discourse.julialang.org/t/recursive-inner-functions-a-thousand-times-slower/85604 "2022-08-11T04:43:21Z")
**Posts on this page:** 1
**Showing post:** 2

<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: [August 11, 2022, 5:48am UTC](https://discourse.julialang.org/t/recursive-inner-functions-a-thousand-times-slower/85604/2 "2022-08-11T05:48:50Z")

</div>

Seems like a self-referential version of [this](https://discourse.julialang.org/t/type-instability-of-nested-function/57007/2), which links to the core Github issue #15276. The problem in that case seems like the compiler gives up easily on inferring the captured value if it changes during runtime, which can be worked around by replacing the closure with a functor, a function-like instance whose type is a `struct` containing captured variables (`struct` and the associated `function` are defined at global scope).

I’m not exactly sure why the compiler gives up on inferring a nested recursive function (this doesn’t look like a world age problem, which involves global scope definitions, and nested method definitions aren’t actually redone as dynamically as global definitions), and the workaround is to define the method at global scope like `g`. If you need to capture other variables, you could make a functor as described before. (EDIT: To be clear, a functor could only capture itself if you struggle with uninitialized `mutable struct`s, and it is unnecessary for calling the function part. I’m talking about capturing other things, like if you wanted to iterate with different steps `g(x-step)` ).

---

_[View the full topic](https://discourse.julialang.org/t/recursive-inner-functions-a-thousand-times-slower/85604)._