add __init__() calls to time_imports macro

[IanButterworth]

Breaks out any __init__() calls. They're on their own lines as a package may have multiple modules with __init__()'s

---

Update (latest)

[oscardssmith]

Can the __init__ go after the package? (also preferably displayed in ms as well)

[IanButterworth]

Can the init go after the package?

Not without storing timing info and much more complicated state management unfortunately.

also preferably displayed in ms as well

I agree, but I wanted to maintain all the info and format that @time uses, and the compilation/recompilation time hasn't been added to @timed so even getting the data to reconstruct the message is nontrivial

[topolarity]

+1 for reporting in milliseconds

It's much easier to compare against the other timings:

julia> @time_imports using CSV
      9.9 ms  Preferences
      0.5 ms  SnoopPrecompile
               ┌ Parsers.__init__():  0.058 ms
     96.3 ms  Parsers 34.65% compilation time
      0.5 ms  DataValueInterfaces
      0.8 ms  DataAPI
      0.4 ms  IteratorInterfaceExtensions
      0.4 ms  TableTraits
     12.2 ms  Tables
      9.6 ms  PooledArrays
     19.0 ms  SentinelArrays
      7.0 ms  InlineStrings
      6.6 ms  WeakRefStrings
     29.1 ms  Test
      3.1 ms  TranscodingStreams
               ┌ Zlib_jll.__init__():  1.855 ms
      2.7 ms  Zlib_jll
      1.4 ms  CodecZlib
      0.6 ms  Compat
      0.5 ms  Compat → CompatLinearAlgebraExt
               ┌ FilePathsBase.__init__():  0.034 ms
     36.9 ms  FilePathsBase
      0.9 ms  WorkerUtilities
               ┌ CSV.__init__():  0.003 ms
    124.2 ms  CSV

[KristofferC]

All compilation time from a package load comes from its __init__, or?

So in

         ┌ Parsers.__init__():  0.058 ms
     96.3 ms  Parsers 34.65% compilation time

What does the 34% (~30ms) of compilation time come from when the __init__ function is so fast?

Regarding the formatting, it would be nice to have it fit on one line.

    96.3 ms  Parsers (34.65% compilation time, __init__: 0.058 ms)

or something?

[IanButterworth]

Re the last point a package can have multiple modules with multiple inits though

[KristofferC]

Re the last point a package can have multiple modules with multiple inits though

True, so I guess the question is if it is possible to only use the "step" printing when there is more than one. But that might be a bit awkward to keep track of that state maybe.

[oscardssmith]

wait. I think the problem is that @time cause the compile time to be different than it otherwise would be.

[IanButterworth]

Updated

[IanButterworth]

@vtjnash is the way this jumps between c and julia ok? I guess it changes the error handling if an __init__() errors

[KristofferC]

Should add precompile(Tuple{typeof(Base.run_module_init), Module}) to the precompile list in generate_precompile.jl.

[vtjnash]

@vtjnash is the way this jumps between c and julia ok? I guess it changes the error handling if an __init__() errors

It seems a bit awkward. The jl_init_restored_modules API can probably just be changed to take a single module at a time so the callback isn't needed for it.