Warning about type instability on demand during compilation

[PetrKryslUCSD]

This is a suggestion for enhancement:

The compiler has I believe sufficient information about type instability when a particular method gets compiled. Would it be possible to implement an option to produce a warning message during compilation that the method was type-unstable? For instance, the names of the variables that were found type-unstable could be reported (together with the line information).

This warning printouts could be enabled by a command-line flag, so that the warning would only be printed when the user desired it.

[vchuravy]

@code_warntype give you mostly that, but on the other hand type-instabilities are not necessarily problematic [1]. So I am not sure I see the additional benefit. My workflow is typically:

1. Profile code
2. Inspect with @code_warntype hot methods to verify that there is no excessive type-instability
3. Do performance tuning

[1] Inherently Union{Nothing, Int} is type-unstable but Julia's compiler got sufficiently smarter over the last releases, that it is now something as fundamental as the iteration protocol is implemented this way.

[PetrKryslUCSD]

I'm not saying that this information is otherwise unavailable. It would just be so much more immediate if I could simply run my code with something like julia --warn-type-unstable instead of manually tracking down the code that I want to stabilize, constructing the arguments to give to the function, and then calling @code_warntype and sifting through the reams of information for the one nugget of gold that the compiler could spit out in five seconds...

[KristofferC]

Outputting this for every function would likely get very spammy so you would need to indicate certain blocks. And that is covered by #10980.

[PetrKryslUCSD]

The output could be very much reduced compared to the @code_warntype: all that would be needed for the user to be able to decide whether they want to invest time to make the function
type stable is (I'm guessing) the name of the variable or expression.

[PetrKryslUCSD]

And, this would obviously not apply to pre-compiled stuff.

[vtjnash]

I think you might be surprised at how noisy such a mode would be. There's a fairly substantial amount of code that either ignores types, or would run worse if it tried to get them at compile-time. As @vchuravy mentioned, usually actually only a small portion of code really benefits that much from compile-time propagation of type information (although that portion benefits from it quite greatly).

[PetrKryslUCSD]

If you think it is a bad idea, I have no objection if you close this issue. On the other hand, if this would make it more likely that performance issues due to type instability might be easier to catch (with a little bit of care to control the amount of output, for instance by enabling it in a block, not globally), would that be easy to do?

[KristofferC]

Future discussion can likely be made in #10980.

[timholy]

Given that we now have union-splitting, typically you don't even care about type-instability per se---it's really runtime dispatch that causes the performance hit.

The best thing to do is run the profiler and then look for top-level red bars in ProfileView. That makes it easy to spot runtime dispatch, while also limiting your investigations to things that actually matter for performance.

[PetrKryslUCSD]

Thanks for the union-splitting blog write-up. Interesting stuff...