time_imports: dataviz (encode load-time graphically)

[tfiers]

• 64 got done (in 95a1465)

It looks like this:

It's not clear, visually, what takes a long time. Two options to encode that info graphically:

• Color gradient
• Node size

For both, question of absolute scale: are we arbiter of what is slow and fast? what if it changes over julia versions. otoh: human patience for these things is fixed (there's references, HCI lit & canon) Also, a few deps each with 100 ms is fine. (say 4 such deps → 0.4 second total) A hundred deps with each 100 ms is not (10 seconds total) So should they get same colour / size?

Aha! we could fix that, by doing both: colour the main node (root package) according to a fixed, opinionated, absolute scale. And the sub-deps get a relative colour and-or size

[tfiers]

Also in the above image, note that the time under the root package is not the total. So. For that last idea, maybe this absolute colour should go in the

• 65

Ye I like that. "Total import time: xx" (in red, or green)

for total import time, we can either tally up the subtotals, or directly measure it, with @time @time_imports using MyPkg. These are not the same (ref:

• https://github.com/JuliaLang/julia/pull/47101

)

[tfiers]

If we size nodes, we need to deal with problem that node size is currently (and by default, in dot), dynamic: longer package names get longer nodes, re

• 10

See also the note on node size in the dot docs here, for if we move to HTML nodes ("NOTE: For releases later than 9 September 2014, one can use shape=plain [..] ")

Maybe we should let labels overflow their containing nodes, as in the first example on that page (https://graphviz.org/doc/info/shapes.html, "a very long label")

I kinda like that. You can still resize the text for long packages (as in #10). But the node size is fixed, and it only changes size for time

[tfiers]

(Closing this, together with

• 65,

will close

• 60

)

[tfiers]

• https://github.com/peng1999/PkgDependency.jl/issues/3

When this is implemented and released, could gently point the 4 people there to this package

[tfiers]

• [x] Try giving every node a fixed size, see what it looks like
  • What's syntax? Will arrows still be correct?

(E.g. about the size of the LinearAlgebra node here:

)

[tfiers]

Playground: link (try shape plain, fixedsize true)

Fixedsize looks kinda ew. And different font sizes too! (for

• 10

)

So I think it's better to let those long packages be. ("Gives character". It's true, aids spatial ~memory).

And instead, resize relatively to original size. So the clue is the fontsize (and not the area of the ellipse / space taken up in graph) Sounds bad, but visually I think it works.

[tfiers]

Oooh, box with invisile edges kinda works!! link

[tfiers]

This one for long labels is nice too: CompilerSupportLibraries_jll [label="CompilerSuppo…_jll"] (better than newline)

[tfiers]

Stdlib should be made smaller (the fade here is not very visible. Plus, smaller more useful (more room for rest))

[tfiers]

(The more I look at text-n-arrows-only, the more I like it)

[tfiers]

With smaller stdlib: link

(and with non faded:)

[tfiers]

Actually, now that we don't show edges, we can turn fixedsize off again. (still set smaller width and height on stdlib -- it just smartly expands width to fit label :) does it for us!) (doc: https://graphviz.org/docs/attrs/width) link

[tfiers]

^ If we do it like that, then

• 88

  • (and its 'dependency' (lol)

    • 89 )

..isn't needed no more

[tfiers]

So: plan: pass a node_size map to to_dot_str. (if not in map, take smallest size, mayb) to_dot_str could do the scaling. it rescales the sizes given to the max and min fontsizes. (could do linear, but also log or sqrt or sth)

for "not in map, take smallest": could then not give those a fontsize, and take it from the default, from node [fontsize={smallest}]

test package. Plots yes, that's big. sth else, that's not as annoying. Maybe from the timholy benchmark ye. another option is DiffEqs.

[tfiers]

Now I'm doing WSL dev, and those two make depgraph_web annoying:

• 96

• 46

..would be good to have dot. Could manually install (apt-get. fastest). Or do

• 52

"shouldn't be too hard" ™️

[tfiers]

Ok plots is a good testcase.

julia> depgraph_image(:Plots, stdlib=false, jll=false)
[ Info: Package "Plots" not found in active project. Using General registry
✓ Crawling registry      Time: 0:00:02
Created /tmp/Plots-deps.png

[tfiers]

Ooh, PyPlot also good:

(this is including jll's (i.e. there are none), excluding stdlib)

[tfiers]

(test) pkg> add PyPlot
[…]

julia> PkgGraph.LoadTime.time_imports("PyPlot");
┌ Info: Running command:
│ `julia --startup-file=no --project=test -e 'using InteractiveUtils; @time_imports using PyPlot'`
└ Live output:
     16.8 ms  VersionParsing
     22.4 ms  Preferences
      0.3 ms  SnoopPrecompile
     78.9 ms  Parsers
     40.6 ms  JSON
      5.9 ms  Conda
     18.4 ms  MacroTools
    528.4 ms  PyCall 2.22% compilation time
      1.2 ms  Statistics
     66.1 ms  FixedPointNumbers
      0.3 ms  Reexport
    124.4 ms  ColorTypes 21.93% compilation time (100% recompilation)
    232.0 ms  Colors
      1.3 ms  LaTeXStrings
    899.6 ms  PyPlot 4.91% compilation time

[tfiers]

è carino

[tfiers]

In the above, the time info text is noisy. better if grey. done in 4a5bcd72d1f3b2cc572e29bc34c80c8fc7a43af1 though that spawned

• 103