# Optim: What optimiser is best if your gradient computation is slow?

**URL:** <https://discourse.julialang.org/t/optim-what-optimiser-is-best-if-your-gradient-computation-is-slow/5487>\
**Category:** Optimization (Mathematical)\
**Tags:** optim\
**Created:** [August 21, 2017, 8:17pm UTC](https://discourse.julialang.org/t/optim-what-optimiser-is-best-if-your-gradient-computation-is-slow/5487 "2017-08-21T20:17:13Z")\
**Posts on this page:** 1\
**Showing post:** 12

<div class="post-metadata">

**Author:** ![vgdev](https://avatars.discourse-cdn.com/v4/letter/v/47e85d/32.png) [@vgdev](https://discourse.julialang.org/u/vgdev)\
**Post date:** [August 22, 2017, 4:03pm UTC](https://discourse.julialang.org/t/optim-what-optimiser-is-best-if-your-gradient-computation-is-slow/5487/12 "2017-08-22T16:03:17Z")

</div>

Well, no, the output of this Volterra process will be used to model the volatility of the stock-price, which is then used to compute the call price by averaging over all paths, resulting in the ‘model’ option price that I try to calibrate to market options prices. So in the end, there is 3 parameters and one objective function, so 3 derivatives.

I thought that the convolution part of my code was the bottleneck, but I should obviously have used btime to check this. However, the gradient call of my full code is still indeed ~100x slower using btime, than just the evaluation of the objective function. What can I do with @code\_warntype ?

---

_[View the full topic](https://discourse.julialang.org/t/optim-what-optimiser-is-best-if-your-gradient-computation-is-slow/5487)._