Add (some) precompilation statements for "standard" stuff

[Michael Schlottke-Lakemper]

For example, creating a new p4est connectivity, a new mesh, refining/coarsening, load balancing etc. are very common operations and might benefit (a little) if cached? OTOH, the functions are all dead simple, so we might not gain much. I was just thinking about it since I saw the following line in @time_imports Trixi:

      0.7 ms  P4est_jll
     97.8 ms  P4est 17.56% compilation time (100% recompilation)

If we should do this, a good set of functions to start with are those used in Trixi 😬

[Hendrik Ranocha]

I am not sure this comes from missing precompile statements. I get

julia> @time_imports using P4est
      0.4 ms  Reexport
     47.9 ms  Preferences
      3.7 ms  CEnum
      0.4 ms  JLLWrappers
      0.2 ms  Zlib_jll
      0.2 ms  MPIPreferences
      0.3 ms  CompilerSupportLibraries_jll
      3.6 ms  MPICH_jll 69.23% compilation time
      0.9 ms  P4est_jll
      0.3 ms  Requires
      3.0 ms  DocStringExtensions 67.09% compilation time
    254.9 ms  MPI 75.37% compilation time (<1% recompilation)
     78.5 ms  P4est 17.23% compilation time

100% recompilation in your report is a hint that invalidations happening earlier are causing this latency issue.

[Hendrik Ranocha]

But we should nevertheless have a look at it and check how it impacts the time of precompiling P4est.jl, using P4est, and running some standard workloads.
Ideally, this should be based on SnoopPrecompile.jl to benefit from native code caching on Julia v1.9 - but we should avoid annoying console output during precompilation.

[Michael Schlottke-Lakemper]

Ideally, this should be based on SnoopPrecompile.jl to benefit from native code caching on Julia v1.9 - but we should avoid annoying console output during precompilation.

Absolutely! If this wasn't clear: it only makes sense to do this if we can benefit from caching...

[Hendrik Ranocha]

Sure - I just wanted to leave enough traces so that someone tackling this can get started directly.