Closed KristofferC closed 2 years ago
Sounds reasonable enough for me, I'd like to hear what @timholy and @kimikage (if he is still around) think.
The conversions, operations, and traits could be possibly moved to Colors.jl for people who want to do additional computation; then we can make this package only serve for dispatching purposes.
Sure, we can do this. Once https://github.com/JuliaLang/julia/pull/42016 works, it won't be necessary to stash these in this package.
JuliaHub shows that this package has ~20K downloads per month while Colors has ~10K. This is a large user base, I guess >50% Julia users?
Thus I believe it's worth considering reducing the latency by moving most functionalities to Colors and making ColorTypes a real interface package.
I don't think this package needs much explicit precompilation. In 1.8 people should get the methods they use (transitively) anyway from their own precompilation scripts.
This package does an almost combinatorial amount of precompilation. This causes the package to be slow enough to load that one has to think a second time if it is worth adding it as a dependency. At the same time, this package is described as "minimalistic" which doesn't really jive with a 0.3 second load time:
Removing the precompilation takes it down quite a bit:
As a reference, we can compare this to loading the whole package manager (of course not using the one in the sysimage):
So the minimalistic package for holding some color types takes twice the time to load as the Julia package manager.
This is unfortunate because I presume a lot of people (like me) want to use the package just to hold values of some type but don't really do any computations with them.
Could the amount of precompilation be reduced, or alternatively, could there be an actual minimalistic ColorTypes package that is very quick to load?