A few things that I believe were mentioned multiple times in this thread and that address or already concur with what you have said:
There are deep reasons for why caching code is so difficult in julia, with its multiple dispatch paradigm coupled with aggressive “devirtualization” - these are the features that make Julia amazing, but they also create compiler difficulties that no other language has had to face;
custom sysimages are a great workaround that you can use right now (edit: unless you package your code more esoterically, like the wonderfully reactive trickery and package embedding of Pluto (but that is also being worked on))
creating sysimages is becoming more and more automated and in principle it can be invisible to the user in future versions of julia (e.g. Keno’s work from last year)
It seems unfair to call this thread unnecessary long but then voice concern over things that were actually already addressed in the thread. These are indeed difficult problems causing frustration for users but (1) we should try to appreciate why these things are a difficult problem and (2) these difficult problems are being solved right now and (3) I personally really appreciate the already enormous progress in the last two years.
C++ overloading + templates give the same problem. The difference between overloading and multiple dispatch is that the latter is semantically dynamic; if we want good performance, it needs to be statically inferred and devirtualized. Overloading also “dispatches” on the combination of types of all arguments, but is semantically static, and thus does not need devirtualization.
Don’t get me wrong, I do appreciate the problems and that proper solutions are being worked on. Just sysimages to me are not one of them. Saying that they can be used is bending reality, there are cases when that’s not true, one example would be Pluto.
As to SnoopCompile putting extra hacks which package maintainers needs to do in their packages also does not feel right to be honest.
This is what we have at the moment to work with… Hopefully this things get phased out at some point.
For what is worth, I suspect SnoopPrecompile (or a similar step, like automatically using the tests as a precompilation step) will remain necessary for quite a while. Fundamentally, the julia compiler simply can not know what needs to be compiled unless you want to compile exponentially many combinations of types (which would be prohibitive).
Would it help to reduce JIT lag when loading a package if types were more restricted in functions?
I know this often is not advantages because functions lose generality, but sometimes we do know what types will definitely not work with particular function.
Not really. A function that has say 4 arguments and each one could be 1000 different types has 1 trillion different possibilities. Suppose you exclude half the possibilities in each argument, 500^4 is still 62 billion… In reality you probably only use 20 options…
It’s fundamentally sparse and the sparseness can only be computed st runtime. The solution is to be able to cache the results, and to have package maintainers give the compiler some examples that catch most of the common results.