Build speed

[ctz]

Hello,

I don't have any direct experience to share of using jiff, but depend on it indirectly via env_logger. In a typical test build -- containing several cryptography libraries, tokio, syn, etc. -- jiff is the slowest dependency to compile.

This isn't breaking the bank or causing any issue, and might be a function of jiff being compiled early-on in parallel with many other crates, but it might nonetheless be something to keep tabs on.

Thanks,
Joe

[BurntSushi]

Thanks! I have noticed this and I've looked into making the compile times faster. The problem is that I don't have a good intuition for where the compiler is spending its time. I would love some help on that front.

(There is also the option of splitting Jiff into smaller crates, but that comes with its own challenges and trade-offs.)

[BurntSushi]

I guess discussions don't show issues that reference them, so I'll link #373 and #372 here.

[exrok]

If you want to know where the compiler is spending its time, I would recommend checking out rustc -Zself-profile if you haven't already. Running it and generating the chrome_profiler.json via measureme/crox, I see that analysis takes up the largest portion of compilation time (1.32s) (running on the main branch of Jiff at the time of posting with the latest nightly Rust compiler, incremental off [compiling like a dependency]):

Codegen took 265ms, although that part is multi-threaded and I'm not running anything else intensive on my 16 core machine.

This should allow you to see exactly where the compiler is spending its time. For instance, I can tell you that typechecking jiff::fmt::strtime::format::{{impl}}::format_one took 3.33ms, or that jiff::tz::concatenated::{{impl}}::get took ~5ms to borrow check.

A brief look at jiff::fmt::strtime::format::{{impl}}::format_one shows a lot of try operators ? which can be slow compile, serde uses a simple macro (when error types match) which avoids the try/from traits which yielded them a "9% improvement compared to ?" in compile time, might be worth a shot. In that same function, the context pattern also looks suspicious for potential slowness.

I'm not sure how helpful it will be (like you said in the other issue, Jiff is large) but at least you'll know where the time is spent if you really want to know.

If you invoke rustc directly, you can get cleaning compile time benchmarks especially with perf. Although, running perf stat -r5 rustc ... after every change to make sure your compile times stay small can drive you a little crazy, ask me how I know.

See:
https://doc.rust-lang.org/beta/unstable-book/compiler-flags/self-profile.html

[BurntSushi]

Would you be willing to measure build speed in the same way as reported here, but with jiff 0.2.14? I'm not expecting miracles here, but I'm hoping #379 might have made a (likely small) impact.

[ctz]

For me this looks like:

- 2.	jiff v0.2.13	3.4s	0.7s (21%)	alloc, std
+ 2.	jiff v0.2.14	3.2s	0.5s (16%)	alloc, std

So, definitely the right direction!