rust-bindgen icon indicating copy to clipboard operation
rust-bindgen copied to clipboard

Bindgen becomes incredibly slow when using `--enable-function-attribute-detection` with newer-style `[[attribute]]` syntax.

Open BGR360 opened this issue 3 years ago • 3 comments

We currently use bindgen 0.59.1 for our very large codebase (~1-2 million lines of C).

The other day, we switched all of our C code from using __attribute__((...)) syntax to using the newer [[...]] syntax. A large majority of our functions have attributes (every fallible function has [[nodiscard]], and the majority of functions are fallible).

This ended up causing bindgen to slow down by a factor of more than 10x. Generating bindings for a given library went from taking between 10 to 20 seconds to taking between 2 and 4 minutes. Disabling --enable-function-attribute-detection resolved the issue.

I took a little look through the code and found the implementation of has_attr:

https://github.com/rust-lang/rust-bindgen/blob/9a9438f3d6a3523c69d7bc890e8608b63dbe38a5/src/clang.rs#L570-L589

I wonder if maybe the call to visit() is recursing down too deep. Like if the attributes are on a function definition, could it be visiting all the statements within the function body? Idk, I don't know the structure of the clang AST very well, and the doxygen doesn't make it very easy to learn, so I'm really just shooting in the dark here.

I suppose it's possible that the issue lies in clang, but we aren't seeing any regression in C compilation speed after switching to the new attribute style, so it seems like that's unlikely to be the case.

Anybody have any ideas as to what could be causing this? We'd like to turn function-attribute-detection back on eventually since it's nice to have #[must_use], but the slowdown isn't acceptable for us.

BGR360 avatar Jun 10 '22 00:06 BGR360

Yeah this is the reason the attribute detection is off by default. I recall looking into this in the past and not finding a particularly better way of finding the attribute, but maybe libclang has exposed something like that now?

emilio avatar Jun 10 '22 07:06 emilio

@emilio Do you have any idea why it's only slower with the [[...]] syntax but not with the __attribute__((...)) syntax?

BGR360 avatar Jun 10 '22 19:06 BGR360

I'll try to investigate this a bit further :)

pvdrz avatar Sep 07 '22 19:09 pvdrz

After taking a look it seems there's not much we can do. The only thing that exposes attributes directly is getAttrs from Decl but clang-sys does not expose anything from the Decl class.

pvdrz avatar Oct 03 '22 16:10 pvdrz

Who says we can't make a PR on clang-sys?

BGR360 avatar Oct 28 '22 18:10 BGR360