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
