Speed up compilation by 20 seconds

[yuyichao]

Do not run precompilation for sys0. It is pretty much a waste of time and many of the precompiled function are not useful for bootstrap anyway. There might be other files that can be omitted for sys0 but this should be the safest one.

On my laptop after this change the compilation time of sys.so changed from 2:26 to 2:28 (which is smaller than the fluctuation) and the compilation time of sys0.so plus sys.so goes down from 5:04 to 4:44.

For clean compilation, this should save some time. For recompilation, sys.so is usually used anyway so it shouldn't be slower.

P.S. The main purpose of this PR is to make me feel less guilty by making the CI slower with #11358 and #11359 .

P.P.S. (Edit) Hopefully no one have mis-read my title as 20x. No, sadly it's only 20 seconds.

[yuyichao]

Hmmm. Is JLOptions().image_file not working on windows? It seems that AppVeyor is not including precompile.jl even for sys.so??

[ihnorton]

On a local build the image_file variable is as-expected: first stage it is NULL, second stage it is the expected path.

[yuyichao]

I've just pushed a new version to see whats happening on the windows CI.
Please feel free to abort the previous one. (Actually, please abort the previous one....)

[yuyichao]

I'm wondering if this is a printing issue on windows. AppVeyor has time stamp for each line and for generating sys.ji it spent way too long on the basedocs.jl so I guess it actually included precompile.jl but didn't print it?

Actually how is the printing of included file names done at sysimg build time?

[ihnorton]

Was just writing the same thing. Very strange. Perhaps put some debug output in precompile.jl itself?

[ihnorton]

Actually how is the printing of included file names done at sysimg build time?

https://github.com/JuliaLang/julia/blob/master/src/toplevel.c#L583-L587

[yuyichao]

... OK try again...

I'm glad the CI is not so busy at the moment....

[yuyichao]

Actually, I don't think it is caused by this PR.

https://ci.appveyor.com/project/StefanKarpinski/julia/build/1.0.4855/job/b00ml44va2vb3eqf

And apparently it is not new either
https://ci.appveyor.com/project/StefanKarpinski/julia/build/1.0.4539/job/nsfh7p955g90tx6q

[yuyichao]

Let's see what the CI think this time.
Maybe related to #11017

[yuyichao]

Interesting!

So the output shifts by one line only for sys.ji ???
https://ci.appveyor.com/project/StefanKarpinski/julia/build/1.0.4858/job/33k6ne5suyr4gmav#L952

[yuyichao]

@tkelman

[yuyichao]

I guess this is not needed anymore after #11274. Incidentally, it also seems to fix the missing precompile.jl in the output. (still think it might be related to #11017 though)

[tkelman]

Was there an actual question?

[yuyichao]

@tkelman I just think the missing precompile.jl in the output might be related to #11017 and I thought you might have some idea about this (and that issue).

See this AppVeyor build and the corresponding code. The output of addresses is supposed to be arround precompile.jl but they are actually around basedocs.jl. The second precompile.jl is also missing from all the AppVeyor output I checked.

[yuyichao]

Here's the link to the patch 024f987

The relavant code is here

-include("precompile.jl")
+if !_is_sys0
+    ccall(:jl_, Void, (Any,), "Loading precompile.jl")
+    ccall(:jl_, Void, (Any,), unsafe_load(cglobal(:jl_current_module, Ptr{Void})))
+    ccall(:jl_, Void, (Any,), unsafe_load(cglobal(:jl_base_module, Ptr{Void})))
+    include("precompile.jl")
+end

In case github decided to purge the commit after I deleted the branch.

[tkelman]

No, if I knew how to fix #11017 I would have fixed it by now.