search

emilk / egui

egui: an easy-to-use immediate mode GUI in Rust that runs on both web and native
https://www.egui.rs/
Apache License 2.0
22.34k stars 1.61k forks source link

Improve compile times of `eframe` #4481

Open emilk opened 5 months ago

emilk commented 5 months ago

eframe currently compiles in about 10s on my M3 MacBook Pro, as measured by

cargo clean && cargo build --timings -p eframe

Getting rid of proc-macros

A lot of that time is waiting for proc-macro and syn so that we can start compiling bytemuck, thiserror, and foreign-types-macros (used by core-graphics, which is used by winit).

Getting rid of the proc-macros in bytemuck should be simple (replace by manual implementation of its unsafe traits for Color32, Vertex etc). Likewise, replacing thiserror should also be fairly trivial.

I haven't looked into foreign-types, but even removing some proc-macro usage should allow some crates to start compiling earlier, hopefully reducing the total end-to-end compilation time.

Other stuff

wgpu

Switching glow for wgpu adds another 10s, i.e. doubling the compilation time. To investigate the compilation time of wgpu, run:

cargo clean && cargo build --timings -p wgpu
YgorSouza commented 5 months ago

Compiling for Linux is also much slower. On my machine (Fedora 40, i7-1260P), cross-compiling eframe for macOS (with --target aarch64-apple-darwin) takes 21s and for Windows (with --target x86_64-pc-windows-msvc) takes 24s, while compiling for the default x86_64-unknown-linux-gnu target takes 78s. With the wgpu feature, it goes up to 104s. I couldn't cross-compile to mac with wgpu because I got an error, and Windows with wgpu took 54s.

shautvast commented 3 months ago

I created a draft PR here https://github.com/emilk/egui/pull/4834 so you can verify if it matches your expectations I don't see a noticeable difference in the compile times though (for cargo clean && cargo build --timings -p eframe)