Then how could we reduce the loading time for Julia and packages?
We have tried to build system image for it via
sys.so: test.jl
julia --trace-compile=precompile.jl test.jl
julia --startup-file=no -J"/home/zhaoli/works/public_code/julia-1.5.3/lib/julia/sys.so" --output-o=sys.o sysimage.jl
gcc -shared -o sys.so -Wl,--whole-archive sys.o -Wl,--no-whole-archive -L"/home/zhaoli/works/public_code/julia-1.5.3/lib" -ljulia
And the improve is still not good enough
[ ~/works/Miracle/NumAMF.jl/compilation @XEON ]:zhaoli$ time julia -Jsys.so test.jl
0.000023 seconds (9 allocations: 368 bytes)
real 0m0.873s
user 0m0.954s
sys 0m0.587s
Startup time has significantly improved in the last few patches and I think 1.6 is also faster than 1.5.3, maybe try that (or maybe even the upcoming 1.7)? What sort of times are you looking for? What are you comparing to? What’s your usecase/how much time will your average program spend after startup?
Thank you for the information.
In fact we need to reduce the extra time cost as much as possible, since the script would be used millions of times in a large loop.
Maybe you would suggest parallelize them, but unfortunately they are mostly serial, i.e. one result could be the input of others.
But the suggested DeamonMode.jl may be promising for us.
The usual suggestion for that kind of usecase is “move the loop into julia” and don’t restart julia all over. Is the restarting over and over a hard requirement?
While julia may look like a scripting language on the surface (and for complex enough problems i.e. multiple minutes runtime, where milliseconds of startup don’t matter, you can certainly use it that way), it is in fact a compiled language. Static compilation is in its infancy (though there may be some movement in the next year or two, we’ll see).
Yes this is just the wrong way to go about it. What you want is to call Julia ONCE and have it do the million iteration loop. This will speed up your loop by many orders of magnitude.