CLIM mail archive
[Prev][Next][Index][Thread]

reducing time overhead of text display (in 1.1)

   Date: Mon, 20 Dec 1993 19:31:46 -0500
   From: miller@cs.rochester.edu
   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
   version.

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
hand.

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.

--David Gadbois
References:
Main Index | Thread Index