When operating on objects, one can have the property access either on:

• call site: const f = (x, y) => x + y;, f(o.x, o.y).
• inside the function: const f = o => o.x + o.y;, f(o); (or similarly, const f = ({ x, y }) => x + y;, f(o);).

From my naive understanding, the first likely uses the call-site's inline caches, while the latter takes those of the function itself. In a scenario, where f is being called with all kinds of objects, as long as they have properties x and y, this in my mind could lead to a megamorphic scenario for the latter, not utilizing inline-caches anymore.

Some general disclaimers here:

• Caring about this is almost always premature optimization. I am interested in obtaining a better understanding how things work in general.
• Other optimizations the compiler does, e.g. inlining f into the call-site, likely makes this irrelevant in typical cases.
• While I do try to read some of the assembler output, my ability to understand it is still rather limited. Multiple places are "and then something I don't understand happens".

With my current knowledge, for destructured parameters, it looks like V8 could potentially swap to the first case, replacing all calls with the property accesses, followed by a call to a modified function that takes the values directly. This is primarily, as the function's body never has access to the object itself in the first place. In a way a "light inlining", though perhaps fully inlining is always preferred. This doesn't seem to be done, but I cannot tell for sure.

Is something about my understanding flawed, does function inlining really solve this almost entirely already, or are there problem-cases? Are there any articles I should read, to strengthen my understanding?