Move restrict to a faster loading package? about imagetransformations.jl HOT 6 CLOSED

among the 1.8seconds using time, about 0.8 seconds are contributed by Interpolations/CoordinationTransformations/StaticArrays, so it definitely worth if we can skip loading them; especially it will be more convenient if we can make ImageShow always loaded with the better restrict implementation.

from imagetransformations.jl.

@timholy how do you think of moving restrict to ImageCore? That way ImageShow could also benefit from this.

https://github.com/JuliaImages/ImageShow.jl/blob/af71e1e1cf012ca1a663325398a17a07f7b79bef/src/showmime.jl#L127-L135

from imagetransformations.jl.

I'm supportive of the idea of splitting it out but a bit reluctant to move it to ImageCore, simply because there are no other "algorithms" in there: it's all traits and views.

We could make a separate ImageUtils package and put it there. We could also split out a subpackage from this one and register it separately, e.g., ImageTransformationsRestrict, and it could continue living here. Other thoughts?

from imagetransformations.jl.

Haven't tried it out, but perhaps we could take advantage of https://github.com/JuliaPackaging/Preferences.jl to come up with a way to lazily compile the module, i.e., if we only need a function, then only compile related parts?

from imagetransformations.jl.

It's been a while since I opened this issue.. and load time (and precomp time) has, as expected, improved with 1.6

julia> @time using ImageTransformations
  1.839368 seconds (3.92 M allocations: 285.683 MiB, 4.28% gc time, 18.44% compilation time)

I'm not too worried anymore, but don't let that stall the idea if you think it's still worth it

from imagetransformations.jl.

I plan to make ImageUtils on top of ImageCore, and then move restrict there.

Because the main purpose of ImageUtils is to boost loading time, it needs to be very conservative to dependencies outside JuliaImages.

from imagetransformations.jl.