Here's an explanation that comes from the point of view of the
application builder (rather than the compiler builder):
Without inlining...
function f(x) {
return 3 + g(x);
}
function g(x) {
return x * 2;
}
If f(x) was getting called a lot and was slow, one way to speed it up
would be to get rid of the function call to g(x). You could do this
by hand (as Adam did) by changing the definition of f(x) in your
source code to..
function f(x) {
return 3 + (x * 2);
}
Or, if your compiler supported it, you could add the inline keyword
to the definition of g(x), something like this:
inline function g(x) {
return x * 2;
}
That would be an instruction (or a clue, depending on the semantics
of the language) to the compiler, replace every call to g(x) with the
code in g(x), effectively making f(x) act like its definition is the
condensed form above, and avoiding the overhead of a function call.
In the case Adam was talking about, though, f(x) looked more like...
{
for (i = 0 to 5) {
// do stuff
stuff = foo + g(x);
}
for (j = 0 to 5) {
bar = goop + g(x);
}
}
...which means that to inline it by hand, he had to write out the
body of g(x) twice in the body of f(x). Which gets error-prone if you
really want g(x) to be exactly the same thing both times you call it.
Hope this helped...
On Sep 5, 2006, at 2:51 PM, John Sundman wrote:
> Tucker:
>
> Thank you. Now I understand.
>
> jrs
>
> On Sep 5, 2006, at 5:46 PM, P T Withington wrote:
>
>> Adam wishes that he could declare a function inline.
>>
>> An inline function is a function that works exactly like a regular
>> function, but through black magic in the compiler, does not require
>> a function call.
>>
>> Of course, if your function is actually a method, things become a
>> bit harder, because a method name binds to a different function
>> depending on the class of `this`. So the compiler needs even more
>> black magic to be able to a) determine if the class of `this` is a
>> constant, and b) if so, what that class is, and c) if that class is
>> sealed, so d) it can actually determine which function the method
>> name will map to.
>>
>> None of this is really black magic. Good compilers (e.g., the Self
>> compiler), do this all the time as a matter of course. It's just
>> that our compiler is a pretty naive little compiler by comparison.
>>
>> On 2006-09-05, at 16:41 EDT, John Sundman wrote:
>>
>>> I don't understand this conversation.
>>>
>>> Can anybody point me to a reference that gives a quick explanation
>>> of inline keywords?
>>>
>>> jrs
>>>
>>> On Sep 2, 2006, at 4:16 PM, P T Withington wrote:
>>>
>>>> On 2006-09-02, at 14:47 EDT, Adam Wolff wrote:
>>>>> I recently completed an optimization task by inlining two
>>>>> levels of
>>>>> method
>>>>> calls. This yielded about a 65% speedup. Independent tests have
>>>>> suggested
>>>>> that the flash player method call overhead is extremely high.
>>>>> How much
>>>>> work would it be to add an explicit inlining feature to the
>>>>> compiler? Can
>>>>> we prioritize this?
>>>>
>>>> It's not trivial to get this right. There are several tasks that
>>>> would need to be accomplished first:
>>>>
>>>> 1) Complete the compile-time class modeling, so we can compute
>>>> most-applicable method at compile time
>>>> 1a) Implement sealing -- you can't do anything if the applicable
>>>> class is not sealed
>>>>
>>>> 2) Complete the compile-time expression analyzer, so you can
>>>> correctly substitute actuals for parameters in the substituted
>>>> code.
>>>>
>>>> Still, this is pretty standard compiler stuff and doing 2 should
>>>> also
>>>> let us write a common sub-expression elimination phase, which would
>>>> mean the programmer wouldn't have to keep doing that by hand...
>>>>
>>>> And it is sure the right thing to do. In-lining by hand just makes
>>>> for a maintenance nightmare.
>>>>
>>>> _______________________________________________
>>>> Laszlo-dev mailing list
>>>> [email protected]
>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>
>>
>
>
> _______________________________________________
> Laszlo-dev mailing list
> [email protected]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
