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.
-
A function called
check_typestablethat 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_warntypeoutput). Why do@code_warntypeand 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_warntypedoesn’t return anything as far as I can see, would be nice to have a datastructure to further process. -
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. -
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.