Closed ChrisRackauckas closed 1 year ago
I'll go by your recommendations, but I think my main points are:
So I updated to make use of the version from https://timholy.github.io/SnoopCompile.jl/dev/reference/#SnoopCompile.precompile_blockers. For some reason I find that way it's written to be much easier to read than the one in https://discourse.julialang.org/t/julia-v1-9-0-beta2-is-fast/92290/17?u=tim.holy, maybe just due to white space.
For the plots, should I be doing that all on staletrees
instead of trees
?
Maybe this should be in a separate "Getting Started" or "SnoopCompiler 101 for Inexperienced Programmers" or something. I think the big thing about SnoopCompile is that now with the precompilation changes and all, it needs to move from an audience of "I know a bit of how Julia works and want to make a good package better" to "this is some standard Julia 201 stuff like type-stability". I don't think your average "just started developing packages" developer should need to know how to dig into the details and fix invalidations. I think it's sufficient for many to just know that (a) invalidations are an issue, (b) here's how I create a report of invalidations and open an issue. If people are opening these issues and the big ones are brought into the conversation, then I think they will be solved.
I agree this has to get a lot simpler. Most of the docs were written in the course of this basically being a research project, trying to understand what factors would affect precompilation. Now that Julia itself is much more capable, this is a much less complex question than it used to be. We definitely need to make the documentation reflect the new world.
In fact what I think we also desperately need is a way to take the analysis that Cthulhu does, but instead of annotating the type-inferred code, instead annotates the raw source text. E.g.,
for (i, x::Any) in enumerate(v)
g[i] = f(x)::Any
end
but making that happen is, I think, quite difficult. https://github.com/JuliaLang/julia/issues/31162 would make this vastly easier, but I don't know lisp and have no intention of learning.
I think we can go with this, and add other forms of plotting later. Thanks @ChrisRackauckas! I'll merge when CI finishes.
Base: 84.08% // Head: 77.04% // Decreases project coverage by -7.04%
:warning:
Coverage data is based on head (
7a6aa05
) compared to base (dcae62d
). Patch has no changes to coverable lines.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
As much as details are nice, sometimes giving something that's easy to copy/repeat is good. Maybe this could be added as a library function (it probably would need to be a macro).