# What does @inline mean?

**URL:** <https://discourse.julialang.org/t/what-does-inline-mean/108516>\
**Category:** General Usage\
**Tags:** question\
**Created:** [January 8, 2024, 1:14pm UTC](https://discourse.julialang.org/t/what-does-inline-mean/108516 "2024-01-08T13:14:55Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![jiang\_ming\_zhang](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jiang_ming_zhang/32/204063_2.png) [@jiang\_ming\_zhang](https://discourse.julialang.org/u/jiang_ming_zhang)\
**Post date:** [January 8, 2024, 1:14pm UTC](https://discourse.julialang.org/t/what-does-inline-mean/108516/1 "2024-01-08T13:14:55Z")

</div>

I see a lot of “@inline function” in a package. What does it mean? According to [https://subscription.packtpub.com/book/programming/9781785880919/4/ch04lvl1sec23/inlining](https://subscription.packtpub.com/book/programming/9781785880919/4/ch04lvl1sec23/inlining), it is just a way to avoid the function call overhead? Therefore, it can be deleted without introducing any error?

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [January 8, 2024, 1:33pm UTC](https://discourse.julialang.org/t/what-does-inline-mean/108516/2 "2024-01-08T13:33:26Z")

</div>

> [@jiang\_ming\_zhang](#):
>
> it is just a way to avoid the function call overhead? Therefore, it can be deleted without introducing any error?

Yes, it’s just a (potential) optimization, and deleting it should not change what the function does. See the [official `@inline` documentation](https://docs.julialang.org/en/v1/base/base/#Base.@inline).

---

<div class="post-metadata">

**Author:** ![AMJ](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/amj/32/214096_2.png) [@AMJ](https://discourse.julialang.org/u/AMJ)\
**Post date:** [January 8, 2024, 1:45pm UTC](https://discourse.julialang.org/t/what-does-inline-mean/108516/3 "2024-01-08T13:45:19Z")

</div>

[Inline 101](https://aviatesk.github.io/posts/inlining-101/) also a good reference written by @aviatesk

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [January 8, 2024, 2:48pm UTC](https://discourse.julialang.org/t/what-does-inline-mean/108516/4 "2024-01-08T14:48:22Z")

</div>

note that what this probably means is the package is old and those `@inline`s should likely be removed. Julia is generally pretty good at figuring out when to inline functions now

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [January 8, 2024, 4:27pm UTC](https://discourse.julialang.org/t/what-does-inline-mean/108516/5 "2024-01-08T16:27:09Z")

</div>

If any function is called using an `llvmcall`, you’ll probably need `@inline`.  
I do not trust the heuristics.

In other cases, it’s hard to get code to be type stable and avoid unnecessary heap allocations, but spamming `@inline` sometimes fixes it, and is probably more robust than finding a particular guilty function that may change with the Julia version.

But I think this is for a very particular style of code, using lots of recursion and building temporary objects, where you’re counting on the compiler to delete all your work.

Another example of the `@inline` heuristics having been bad – and it’s been maybe a year since I checked this one, so maybe my info is old! – is `ForwardDiff`. It adds `@inline` to everything, and these are essential for performance.  
Because `ForwardDiff` doesn’t provide `@fastmath` specializations, `@fastmath` is often a hefty pessimization for `ForwardDiff` code.

All that said, my advice would be not to worry about adding `@inline` unless you already noticed some performance problem that you know can be fixed by it.
