# \[RFC\] Ideas for tools around type stability / optimization

**URL:** <https://discourse.julialang.org/t/rfc-ideas-for-tools-around-type-stability-optimization/33850>\
**Category:** Tooling\
**Tags:** proposal\
**Created:** [January 27, 2020, 2:28pm UTC](https://discourse.julialang.org/t/rfc-ideas-for-tools-around-type-stability-optimization/33850 "2020-01-27T14:28:47Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://discourse.julialang.org/u/jules)\
**Post date:** [January 27, 2020, 2:28pm UTC](https://discourse.julialang.org/t/rfc-ideas-for-tools-around-type-stability-optimization/33850/1 "2020-01-27T14:28:47Z")

</div>

When optimizing slow code, people, especially newcomers, are pointed to tools like `@code_warntype` and profilers like `ProfileView`. I wanted to collect some ideas for improvement because I think some steps could be made easier or more automated. Here are some of my ideas, I hope that not too many have been discussed elsewhere, I didn’t find much at least.

1. A function called `check_typestable` that takes an expression and returns a tree structure in which for every sub function call there is a Boolean indicating whether it’s type stable or not (by that I mean no red in the usual `@code_warntype` output). Why do `@code_warntype` and scan the large output if I can first skim if there’s a problem at all? This could also be a nice thing to check for in tests so that there are no regressions. `@code_warntype` doesn’t return anything as far as I can see, would be nice to have a datastructure to further process.

2. Optional formatted HTML output for all `@code_` macros. I know that many people love the simplicity of the REPL but there is only so much you can do with static text output. If we could think of interactive interfaces that would let people fold or expand certain long type signatures for example, or lower the visual saliency of all this `%1 = ` stuff that’s obstructing the more important information. Imagine replacing every complex type with a “legend” marker and having a legend on the side for example, that could help getting a quicker overview.

3. Combining Profiler output with type stability information. It would be great if for every flame graph entry there was also information on the profiled functions so that it would be easier to reach conclusions where optimizations could be most effective. I think that’s a quite manual process now, look at line numbers, check function, maybe run that with `@code_warntype`, etc.

I would actually like to contribute to something like 2, are there already efforts underway, maybe in Juno? The stack traces there are for example already more readable than in the REPL, so they have the right idea.

---

<div class="post-metadata">

**Author:** ![longemen3000](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/longemen3000/32/7298_2.png) [@longemen3000](https://discourse.julialang.org/u/longemen3000)\
**Post date:** [January 27, 2020, 2:48pm UTC](https://discourse.julialang.org/t/rfc-ideas-for-tools-around-type-stability-optimization/33850/2 "2020-01-27T14:48:02Z")

</div>

Related in some way:

> [@Code\_native opcode annotations](https://discourse.julialang.org/t/code-native-opcode-annotations/29562):
>
> For those of us not yet fluent in reading assembly, code\_native output could be enhanced with human-readable annotations of what the opcodes represent. This will save us from constantly searching through docs to find meanings of the more obscure opcodes. Are there any existing annotation tools? I searched and did not find anything. I’m surprised that no one already built a simple web app that annotates blobs of assembly. This doesn’t seem too difficult to introduce to Julia’s code\_native funct…

I totally support that. Maybe creating an struct that holds the info is better than raw text

---

<div class="post-metadata">

**Author:** ![dilumaluthge](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dilumaluthge/32/29283_2.png) [@dilumaluthge](https://discourse.julialang.org/u/dilumaluthge)\
**Post date:** [January 27, 2020, 2:51pm UTC](https://discourse.julialang.org/t/rfc-ideas-for-tools-around-type-stability-optimization/33850/3 "2020-01-27T14:51:22Z")

</div>

You may also be interested in:

> **[GitHub - JunoLab/Traceur.jl](https://github.com/JunoLab/Traceur.jl)**
>
> Contribute to JunoLab/Traceur.jl development by creating an account on GitHub.

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://discourse.julialang.org/u/jules)\
**Post date:** [January 27, 2020, 2:53pm UTC](https://discourse.julialang.org/t/rfc-ideas-for-tools-around-type-stability-optimization/33850/4 "2020-01-27T14:53:20Z")

</div>

Oh that looks nice, I’ll have a look. Haven’t seen that mentioned anywhere so far