Explicit that calls to external methods should be traced back to MyPackage

[serenity4]

This should help users avoid issues when directly precompiling methods they don't own in their Startup package.

I also changed @snoopi_deep to @snoop_inference and @snoopr to @snoop_invalidations, I think those were leftovers from timholy/SnoopCompile.jl#386.

[timholy]

Thanks, this is indeed helpful.

[timholy]

This is not true, and indeed it's the main reason for the existence of PrecompileTools.

[serenity4]

I am observing this behavior though, which motivated the PR. Perhaps that is a bug?

The case I stumbled upon was with this precompilation workload on a dummy package:

module TestPackage

using Meshes # package for which to precompile methods
using PrecompileTools

function workload()
  geometry = PolyArea((0, 0), (1, 0), (1, 1), (1, 0))
  simplexify(geometry)
end

@compile_workload begin
  workload()
end

end # module

Essentially, with the workload() function indirection, I get correct precompilation:

julia> using TestPackage

julia> using Test

julia> @time @eval TestPackage.simplexify(TestPackage.PolyArea((0, 0), (1, 0), (1, 1), (1, 0)))
  0.002689 seconds (1.39 k allocations: 64.922 KiB, 91.12% compilation time)

While having an "inline" workload as

@compile_workload begin
  geometry = PolyArea((0, 0), (1, 0), (1, 1), (1, 0))
  simplexify(geometry)
end

does not seem to retain compilation results:

julia> @time @eval TestPackage.simplexify(TestPackage.PolyArea((0, 0), (1, 0), (1, 1), (1, 0)))
  4.072428 seconds (40.46 M allocations: 1.983 GiB, 3.30% gc time, 99.99% compilation time)

Should I file an issue about that? If the function indirection should not be necessary, I can remove that doc change and we can merge the other renamings.