# Why does JET give these "runtime dispatch detected" lines for some LDLFactorizations calls in Tulip

**URL:** <https://discourse.julialang.org/t/why-does-jet-give-these-runtime-dispatch-detected-lines-for-some-ldlfactorizations-calls-in-tulip/79583>\
**Category:** Performance\
**Tags:** dispatch, jet\
**Created:** [April 16, 2022, 11:01pm UTC](https://discourse.julialang.org/t/why-does-jet-give-these-runtime-dispatch-detected-lines-for-some-ldlfactorizations-calls-in-tulip/79583 "2022-04-16T23:01:04Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![mtanneau](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mtanneau/32/17787_2.png) [@mtanneau](https://discourse.julialang.org/u/mtanneau)\
**Post date:** [April 18, 2022, 1:24am UTC](https://discourse.julialang.org/t/why-does-jet-give-these-runtime-dispatch-detected-lines-for-some-ldlfactorizations-calls-in-tulip/79583/3 "2022-04-18T01:24:08Z")

</div>

This is interesting 🤔  
I’ve always had the (mis?) conception that using `BigFloat` in Tulip was going to be terribly slow, because that’s the way things are with `BigFloat`. If there were any compiler-related inefficiencies, I would have expected them to be negligible anyway.

As for JET: I have very little (virtually zero) experience with it, so I can’t really comment on why that line is flagged. I ran the code you shared (Julia1.7, Tulip@master), and JET also reported hundreds of issues/runtime dispatch that were mostly related to broadcast and the use of `@printf`

For instance, I saw a large number of such messages from JET:

```julia
││┌ @ broadcast.jl:516 Base.Broadcast.length(%157)
│││ runtime dispatch detected: Base.Broadcast.length(%157::Base.OneTo{Int64})

```

@nsajko: I you want to open an issue in Tulip.jl to track this, I will happily help the best I can.

---

_[View the full topic](https://discourse.julialang.org/t/why-does-jet-give-these-runtime-dispatch-detected-lines-for-some-ldlfactorizations-calls-in-tulip/79583)._