[usamoi]

I did a little investigation in compilation time and found the most time-consuming part in pgrx is rustc codegen: most bindings of PostgreSQL are not used but rustc spends time in generating machine code of pg_guard wrappers. I just read https://kobzol.github.io/rust/rustc/2024/03/15/rustc-what-takes-so-long.html and it said, Because if you just build an intermediate artifact (like an .rlib, which is what your crate dependencies compile into), that won’t compile #[inline]-d and generic functions, and also the linker won’t be involved. So, I thought #[inline] should help compilation time.

Marking pgrx_pg_sys bindings inline reduces compilation time. It took 150 seconds to build pgrx before and it takes 36 seconds to build pgrx now.

cargo build --no-default-features --features pg13 --release --timings

Before this PR:

After this PR:

The “codegen” times are highlighted in a lavender color.
The “custom build” units are build.rs scripts, which when run are highlighted in orange.

Inlining prevents unused codegen in macros, so it's faster.

[eeeebbbbrrrr]

Wow. That’s such an improvement that I kinda don’t believe it.

Are those both timings with “cargo clean”?

[usamoi]

Are those both timings with “cargo clean”?

Yes.

[eeeebbbbrrrr]

I’m gonna go ahead and merge. Would you mind linking that blog post you linked on discord here in this PR too?

[usamoi]

Would you mind linking that blog post you linked on discord here in this PR too?

It's beneficial.

[eeeebbbbrrrr]

Apparently this came about fromm https://kobzol.github.io/rust/rustc/2024/03/15/rustc-what-takes-so-long.html

Specifically this sentence:

Because if you just build an intermediate artifact (like an .rlib, which is what your crate dependencies compile into), that won’t compile #[inline]-d and generic functions, and also the linker won’t be involved

[eeeebbbbrrrr]

BTW, @usamoi… thanks. This is a huge win.

[workingjubilee]

Ah, this is because of an artifact of rustc that is somewhat dependent on how things currently work, rather than something necessarily true, though I suppose we can always revert it later if things do change significantly.

Namely, when a function is inline, currently rustc defers codegen into the rlib until it reaches the actual callsite.