MRIReco load time

[cncastillo]

I was checking how long some packages were taking to load (as KomaMRI is taking around 3s to load), and I got the following results:

julia> @time using KomaMRI # This is a lot! around 1.4s is just loading MRIReco
  3.354859 seconds (6.92 M allocations: 351.951 MiB, 5.74% gc time, 13.79% compilation time: 26% of which was recompilation)

julia> @time using KomaMRICore # Base simulation package
  0.688178 seconds (906.46 k allocations: 59.652 MiB, 2.81% gc time, 20.73% compilation time: 78% of which was recompilation)

julia> @time using MRIReco
  1.399110 seconds (1.87 M allocations: 111.571 MiB, 2.10% gc time, 2.37% compilation time)

(v1.10) pkg> why Polynomials # 257.3 ms
  MRIReco → MRIOperators → Wavelets → DSP → Polynomials

(v1.10) pkg> why LowRankApprox # 646.0 ms
  MRIReco → MRIOperators → LowRankApprox

(v1.10) pkg> why FillArrays # 102.9 ms
  MRIReco → MRIOperators → Distributions → FillArrays

(v1.10) pkg> why Distributions # 207.6 ms
  MRIReco → MRIOperators → Distributions

(v1.10) pkg> why Unitful #  193.5 ms
  MRIReco → Unitful

Here, I just showed the packages that take more than 100ms to load (using @time_imports).

It may be worth considering moving some to a package extension. I would be happy to help, but I need an overall idea of why each package is needed.

LowRankApprox.jl is the heaviest, so that would be a good one to target or Distributions.jl. I believe that Unitful.jl could probably be easily moved to a package extension.

[aTrotier]

@cncastillo I think :

• Unitful -> only used to create an axisArray that stores the dimension https://github.com/MagneticResonanceImaging/MRIReco.jl/blob/master/src/Tools/ImageData.jl
• LowRankApprox -> used in ExpApproximation.jl (psvd function). I think the operator is used for off-resonance reconstruction
• Distribution : seems I can remove it without issues in CI... remove Distributions dependency #220

@tknopp do you know what Distributions was used for ?

[aTrotier]

Thanks @tknopp for merging #220

• For LowRankApprox is it possible to only use LinearAlgrebra : svd ? remove LowRankApprox dependencies #222
• Do we really need to define the AxisArray with unitful.jl ? The fov is always suppose to be in mm, if we really need that we can add unitful to MRIFiles to simplify the conversion from AxisArray to NIfTI for example no ?

[tknopp]

I don't think changing psvd to svd is an option at that point. The partial svd is much faster and in particular is tuned to the required rank.

One option might be to switch to the package TSVD.jl. Attached are my timings:

Here one has to take into account that at least FFTW is loaded anyway. SparseArrays is often also loaded.

[aTrotier]

@cncastillo can you try with thus changes :)

Unitful is only used in :

function makeAxisArray(I::AbstractArray{Complex{T},6}, acqData::AcquisitionData{T,D}) where {T,D}

  offset = zeros(3)*Unitful.mm
  shape = ones(Int, 3)
  shape[1:D] .= encodingSize(acqData)
  spacing = fieldOfView(acqData) ./ shape * Unitful.mm

  im = AxisArray(I,
		   Axis{:x}(range(offset[1], step=spacing[1], length=size(I,1))),
		   Axis{:y}(range(offset[2], step=spacing[2], length=size(I,2))),
		   Axis{:z}(range(offset[3], step=spacing[3], length=size(I,3))),
		   Axis{:echos}(1:size(I,4)),
       Axis{:coils}(1:size(I,5)),
       Axis{:repetitions}(1:size(I,6)))

  return im
end

Right now, the geometry stored along the reconstructed array is not required by any functions (except writing a nifti files) maybe we can move the function in MRIFiles because the post-processing steps are generally applied on NIfTI

[tknopp]

We could probably remove ImageUtils and Unitful from MRIReco. The method above could then be moved into a package extension (requiring only ImageUtils since that already requires NIfTI and Unitful). It would be an extension for MRIBase I think since they only dependency is AcquisitionData .