# Making Turing Fast with large numbers of parameters?

**URL:** <https://discourse.julialang.org/t/making-turing-fast-with-large-numbers-of-parameters/69072>\
**Category:** General Usage\
**Tags:** turing\
**Created:** [October 1, 2021, 7:53pm UTC](https://discourse.julialang.org/t/making-turing-fast-with-large-numbers-of-parameters/69072 "2021-10-01T19:53:43Z")\
**Posts on this page:** 1\
**Showing post:** 122

<div class="post-metadata">

**Author:** ![tobias.alfers](https://avatars.discourse-cdn.com/v4/letter/t/48db29/32.png) [@tobias.alfers](https://discourse.julialang.org/u/tobias.alfers)\
**Post date:** [October 31, 2021, 8:22am UTC](https://discourse.julialang.org/t/making-turing-fast-with-large-numbers-of-parameters/69072/122 "2021-10-31T08:22:11Z")

</div>

Thanks Mohamed for stressing this issue.

Some months ago my colleague and I tried a slightly different version of this model with LazyArrays 0.16.16 and the performance was way better (around 44 seconds; but not as good as Stan) before updating to LazyArrays 0.17.0. So maybe there is a change in LazyArrays internals that Turing is not handling very well?

I am trying to benchmark this again with downgrading to LazyArrays 0.16.16 but there are some dependency issues going on. Maybe I can find a manifest.toml somewhere to replicate this phenomenon…

---

_[View the full topic](https://discourse.julialang.org/t/making-turing-fast-with-large-numbers-of-parameters/69072)._