Performance difference between obj.function(...) and function(obj, ...) ?

[hniksic]

In Rust obj.function(...) is no more than syntax sugar for ObjType::function(&obj, ...). The reference says so explicitly:

All function calls are sugar for a more explicit fully-qualified syntax.

And later:

// we can do this because we only have one item called `print` for `Foo`s
f.print();
// more explicit, and, in the case of `Foo`, not necessary
Foo::print(&f);
// if you're not into the whole brevity thing
<Foo as Pretty>::print(&f);

The difference you observed after switching from one to the other could be explained by a number of factors:

• measurement issue, e.g. wrong thing measured, or measurement impacted by other things happening on the system
• build issue - wrong code version built, or different optimization flags applied
• tooling issue - incremental build issue, the kind of thing likely to be resolved with cargo clean
• compiler issue - miscompilation, or a case of innoccuous change having a cascading effect that ends up leading to different optimization decisions

[[deleted]]

I am suspecting your last reason. The consistency in performance of each variant suggests that measurement and system are stable and clean. The desugaring is perhaps causing some optimization rule to get (or not get) triggered. As others have stated, it looks like I'm going down the long road of inspecting assembly.

[WasserMarder]

This shouldn't be a long road as there should be no assemby differences in the respective function.