CLIM mail archive
reducing time overhead of text display (in 1.1)
Date: Mon, 20 Dec 1993 19:31:46 -0500
X-Government: Live the nightmare.
> From: chyde@BBN.COM
> Date: Mon, 20 Dec 93 19:07:16 EST
> I think that there should be two versions of functions: the
> order-dependent and the order-IN-dependent. the order-dependent
> doesn't even use keywords, has a fixed set or req'd args. the other
> one is actualy a macro that expands into the dependent function, and
> fills in missing args. that way, the pain occurs only at compile time.
> the programmer is free to use either one, and knows the penalty for
> doing so (and by compiling it out, it's virtually non-existant).
The real question is, why doesn't the compiler do this ANYWAY, without
making the programmer do all that work? Then when the options/keywords
are known at compile-time, you get the "fast" order-dependant no options
Last time I checked, the Python compiler in CMU CL has a concept of
"maybe inlining" where it tries inlining a function to see if there is
any savings. In the process, it compile-time evaluates and dead-code
eliminates a lot of the keyword parsing, so that a call with fixed
keyword arguments does not have any overhead.
The Genera compiler has a fairly hairy set of macros that map
keyword-taking functions into positional calls. This works well but
has the disadvantage that users have to do the optimization halfway by
Ideally, I'd like a combination of the two approaches where the
compiler automatically generates multiple netry points into a function
so that calls can jump in wherever the least amount of work is needed.
This would have the advantage of the Python scheme of being
user-transparent and generally available while also avoiding code
bloat and allowing for callee redefinition ala Genera.
Main Index |