On Fri 04 Jun 2010 09:25, No Itisnt <theseaisinh...@gmail.com> writes:
> I was thinking about inlining, contant propagation, and that class of > optimizations recently. Wouldn't Guile's module system (specifically, > module-set!) interfere with doing these optimizations on module-level > bindings? Yes and no, I think. Inlining is fun, but effectively prevents late binding. When you know you want to integrate a whole block of code, the best thing to do is to express that lexically, by enclosing the whole thing in a `let', for example. You can also specify that certain important bindings are to be inlined by default, for example using define-inlinable, as defined in srfi-9. See http://www.scheme.com/csug8/use.html#./use:h6 for another discussion. > (Bonus whine: Guile currently does this with primitives like +) If it didn't, Guile would be quite slow :) Though, this should be an option. > Off the top of my head, R6RS makes all imported bindings immutable. > How often are cross-module set!s used in Guile? Not often. > Maybe exported bindings could be made immutable by default, and the > module definition would explicitly name variables that should be > mutable by external code, so the compiler knows not to optimize them. > Correct me if I'm wrong here, I've never dealt with this in practice > so I'm just musing out loud. I wouldn't worry about it for now. We can always choose to inline more in the future, but for now the performance bottleneck is native compilation, which will take a couple years to sort itself out nicely. Also consider that the logical end of an aggressive inliner is a whole-program compiler, and I would not want to hack on a program compiled with such a thing: if something does not go according to plan, instead of debugging a live being, you have to do an autopsy on a corpse :P Cheers, Andy -- http://wingolog.org/
