# Why isn't \`size\` always inferred to be an Integer?

**URL:** https://discourse.julialang.org/t/why-isnt-size-always-inferred-to-be-an-integer/75139
**Category:** General Usage
**Tags:** inference, compilation
**Created:** [January 24, 2022, 4:09pm UTC](https://discourse.julialang.org/t/why-isnt-size-always-inferred-to-be-an-integer/75139 "2022-01-24T16:09:16Z")
**Posts on this page:** 5
**Page:** 2

<div class="post-metadata">

### Author: ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [January 24, 2022, 7:00pm UTC](https://discourse.julialang.org/t/why-isnt-size-always-inferred-to-be-an-integer/75139/21 "2022-01-24T19:00:32Z")

</div>

@mbauman dont type instabilities also account for a lot of (pre)compile time, because its more work for the compiler to resolve types?

In my experience fixing type stability absolutely reduces compile time.

---

<div class="post-metadata">

### Author: ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [January 24, 2022, 7:32pm UTC](https://discourse.julialang.org/t/why-isnt-size-always-inferred-to-be-an-integer/75139/22 "2022-01-24T19:32:26Z")

</div>

You’re absolutely right — I was wrong. As Chris notes in his magnum opus of [DifferentialEquations.jl #786](https://github.com/SciML/DifferentialEquations.jl/issues/786):

> The last thing, and the major step forward, was [SciML/DiffEqBase.jl#698 (comment)](https://github.com/SciML/DiffEqBase.jl/pull/698#issuecomment-897188008) . As it explains, using a function barrier can cause inference to not know what functions it will need in a call, which makes Julia **seem to compile a whole lot of junk**. That can probably get fixed at the Base compiler level to some extent, as the example there was spending 13 seconds compiling `(::DefaultLinSolve)(::Vector{Float64}, ::Any, ::Vector{Float64}, ::Bool)` junk which nobody could ever call, since any call to that function would specialize on the second argument (a matrix type) and so it should’ve been compiling `(::DefaultLinSolve)(::Vector{Float64}, ::Matrix{Float64}, ::Vector{Float64}, ::Bool)` . But since that call was already precompiled, if inference ends up good enough that it realized it would call that instead, then bingo compile times dropped from 16 seconds to sub 3. That’s a nice showcase that the easiest way to fix compile time issues may be to fix inference issues in a package, because that can make Julia narrow down what methods it needs to compile more, and then it may have a better chance of hitting the pieces that you told it to precompile (via a using-time example in a precompile.jl).

---

<div class="post-metadata">

### Author: ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [January 24, 2022, 8:11pm UTC](https://discourse.julialang.org/t/why-isnt-size-always-inferred-to-be-an-integer/75139/23 "2022-01-24T20:11:50Z")

</div>

Yeah thats my experience too. You can see the pyramids of compilation calls shrinking and disappearing from the flame graph as you remove unstable code. Boxed vars need much more llvm/native code than Ints and Floats.

---

<div class="post-metadata">

### Author: ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [January 24, 2022, 9:20pm UTC](https://discourse.julialang.org/t/why-isnt-size-always-inferred-to-be-an-integer/75139/24 "2022-01-24T21:20:06Z")

</div>

> [@joa-quim](#):
>
> he source of the `Any's` is the `kwargs` tht are converted into a `Dict(:symbol, Any)` and from there anything extracted from the `Dict` is a `Any` . Have no idea on how to work around this.

Why do you need to convert kwargs to a Dict? Can’t that function use them as-is, or at least convert to a namedtuple (it’s type-stable)?

---

<div class="post-metadata">

### Author: ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)
#### Post date: [January 24, 2022, 11:57pm UTC](https://discourse.julialang.org/t/why-isnt-size-always-inferred-to-be-an-integer/75139/25 "2022-01-24T23:57:09Z")

</div>

The very truth is that when I started this around 2015 I was so happy to have achieved the goals of being able to easily parse multi-type inputs that didn’t look back. Since then the code grew quite a bit and now is not at all obvious to do changes. However, more recently I made experiments in parsing the kwargs directly and it made no difference in what respect the `Any's` side. Basically, if one want to accept multi-type inputs I think there is nothing we can do other than to try limit the `Any's` propagation.

[Previous page](https://discourse.julialang.org/t/why-isnt-size-always-inferred-to-be-an-integer/75139.md?page=1)
