We used to do this, and lost that feature in the remodularization of the compiler. It should be easy enough to re-introduce this special case, then we could measure and find out.
On 2006-09-02, at 17:18 EDT, David Temkin wrote: > There was some talk about making the compiler automagically inline, > say, SetAttribute. How far would that go in terms of performance? > > On Sep 2, 2006, at 1: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
