Closed mtanneau closed 3 years ago
@iSoron I have no experience with MakeFiles, so you may want to try this for yourself before merging.
Here are the commands I used (locally) to generate the sysimage and run the examples:
# Generate the precompile statements
julia --project --trace-compile=precompile.jl benchmark/run.jl test/case14.json.gz
# Build sysimage
julia --project src/sysimage.jl
# Run the test case again, this time with the sysimage
julia --project --sysimage=build/sysimage.so benchmark/run.jl test/case14.json.gz
Thanks @mtanneau, I will have a closer look into this. The system image is currently used just for accelerating loading package dependencies (e.g. using JuMP
). That helps running unit tests faster (see make test
). If we include the package itself in the system image, then we would need to recreate it after each code change, which would make them unsuitable for tests. But you make a good point that system images could also speed up the benchmarks. Perhaps there should be two system images: one for unit tests and one for benchmarks.
Right. I was operating under the (incorrect) assumption that the sysimage would only be used for benchmarks, not for testing.
That being said, the UnitCommitment
package is not included in the sysimage anyway, i.e., no UnitCommitment
functions will be compiled a priori. So you shouldn't need to rebuild the sysimage after each code change; only after when you update the dependencies (which should already be the case).
[EDIT]: this is making me realize that I broke the make test
pipeline in #2...
Merged in 9957894bdc892cca07e55600ffde907aa493ddd2 with some small fixes to the Makefile
in 4146aa9f95757076ca90b2a585511d0ac377cf59. Thanks again, @mtanneau!
Although precompile.jl
includes some UnitCommitment
functions, it seems like PackageCompiler is in fact not including them in the system image. If that is indeed the case, then one system image file is fine for both purposes.
This PR adds a list of precompile statements for generating the sysimage (see the PackageCompiler docs for background).
The logs below show that, in the current form, there's virtually no gain to using a sysimage. That's because everything still needs to be compiled at runtime. When the sysimage is built with precompile statements, runtimes are improved significantly.
The precompile statements are generated by running the
test/case14
example. Basically, all functions that are compiled while running this test case will be included in the sysimage. It's hard to be exhaustive, but I guess this should cover most typical cases.Log with no sysimage:
Log with sysimage, before:
Log with sysimage, after: