bloat #17
Labels
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: M-Labs/nac3#17
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The binary size is surprisingly large:
(Not a high priority issue)
LLVM is statically linked and dynamic linking isn't supported by llvm-sys. This PR adds it:
https://gitlab.com/taricorp/llvm-sys.rs/-/merge_requests/4
@ychenfo please work with llvm-sys upstream to get this PR edited as per review comments and merged.we want our own LLVM build and link it staticallyMay also be worth initializing only the targets we use instead of
Target::initialize_all
. Could reduce startup time and/or memory consumption (TBD).Alternatively just build LLVM with only the used targets.
With default nixpkgs LLVM (containing all targets):
149M ./target/release/libnac3artiq.so
Adding
"-DLLVM_TARGETS_TO_BUILD=X86,ARM,RISCV"
when building LLVM (editingpkgs/development/compilers/llvm/12/llvm/default.nix
):109M ./target/release/libnac3artiq.so
Removing debug info also reduce 149M to ~100M.
Apart from size bloat, I'm also a bit concerned about compilation time. Our development workflow will modify nac3core, and compile nac3artiq for example. Currently the compilation takes ~18s on my machine for release build and 11.5s for debug build, which is quite slow... (and slower on @ychenfo 's machine, taking over 1min iirc, maybe he should try tmpfs...)
Using lld and a nightly flag which shares generics between traits can reduce the compilation time to 11s for release build and 7s for debug build.
Removing debug info, using the latest nightly with the above flags reduced the full release build compile time from 1m55s to 58.5s on zeus.
Note that
nix build #.nac3artiq
will now fail withwhich I have no idea, maybe the LD_LIBRARY_PATH is messed up?
I have removed the ffi dependency so it should work now. Might break the Windows build though and do we really want fenix and rust-nightly?
Note that in many cases rustc can be made to stop whining about "XYZ may not be used on the stable release channel" by simply setting the environment variable
RUSTC_BOOTSTRAP=1
.libgccjit might perhaps be an alternative to LLVM
Another alterntive is cranelift but 32-bit RISC-V and 32-bit ARM support is lacking.