Reply To: Inlining functions vs. call/return

For simple, non-iterative functions, such as getter/setter methods on objects, I suspect there can be substantial performance gains from inlining vs. calling them. By inlining such function invocations, most (if not all) of the function’s load operations can execute earlier (be raised within the calling EBB) than would likely happen if the function were to be called. So I suspect that inlining such simple functions will reduce the number of unused/no-op-ed slots executed, thus improving both speed and code density. In my experience, the sequence of:

1. get (some property of an object),

2. make a simple change,

3. set the property to the changed value

happens so often in object-oriented code that I think aggressive inlining of such sequences will make (compiled) OO-language code really fly on a Mill.

—-

[1] By simple, here I mean a function whose real work could be done in fewer operations than the target Mill could do in three full cycles, if the load latency were minimal (result available in the next cycle after the load.) For most getter methods, the real work is just a single load (usually from a compile-time known offset) from a base address. Likewise, a setter method is often just a store (again, frequently with a compile-time-known offset) to an address.

So an inlined version of a simple getter/setter function could take up merely a single load/store-capable slot in a much wider instruction. A fraction of a Mill instruction is faster and more compact than three full instructions (call, at least one instruction for the function body, return.) And IMHO, simple methods are called frequently in much object-oriented code.