[zephen]

> someone writing a library with a costly abstraction

That's not what happened here.

> it's not like C++ doesn't have some costly abstractions

This is simultaneously both completely orthogonal to my observation that the Rust FFI is borked, and a great example of a problem that wouldn't happen in C++, because in C++ you could completely ignore the costly abstractions if necessary.

[Aurornis]

> That's not what happened here.

Yes, it's what happened here. The article is about debugging the author's own abstraction types that had some incorrect assumptions.

You do not need these wrapper types to call C functions. If the author had removed the complex extractions and called the extern "C" function directly (as is standard in Rust) there would not be the additional overhead.

[saghm]

> > someone writing a library with a costly abstraction

> That's not what happened here.

Yes it is. Where do you think the `FFISafe` type that they used came from? It's not anything inherent to how Rust does FFI; it's a type someone wrote in an attempt to try to provide an abstraction, and that abstraction happened to have a cost. There's absolutely no reason anyone has to use it in order to do FFI in Rust.

[zephen]

The extra time was being taken up in the identical assembly language function.

Fixing it took wizardry.

[saghm]

The time was taken by the code around the assembly language. It was an abstraction someone wrote in a way that happened not to be efficient. The ability of someone to write a costly abstraction doesn't take away from Rust any more than the possibility of doing that in C++ would from whether C++ has them.

[Dylan16807]

It was caused by the code around it, but the actual CPU cycles stalled out in the assembly language, making it much harder to find the problem.

Is how I understood the post.

Anyway there's noting wrong with rust FFI. The overhead was because this function wanted to support two options and didn't implement that in the best way.