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

Re: reducing time overhead of text display (in 1.1)

    Date: Wed, 22 Dec 1993 11:51 EST
    From: kanderso@BBN.COM

    ...
    
    CLIM has magic in it.  In fact, things like

    (accepting-values ... (setq x (accept ...)))

    leading to popping up a dialog box, is FM, and I'd like to know who thought
    of it, and thank them, and the guys who programmed it to.  Thank you.

The stream-based model for dialogs probably originated with Mike McMahon
during the Dynamic Windows project.  I believe that Bill or Dennis wrote
the first code for this in CLIM.  I invented the idea of a "view" that
mediates between a presentation type and a gadget, and Chris Richardson
and I wrote the code to make gadget dialogs work.

    However, what the user sees is a dialog box, like he sees in other
    applications.  The user is frustrated when the application feels a little
    slow, or worse pieces of it are unusable.  Management gets frustrated, and
    blames "CLIM" or "Lisp" because it is easy to blame things one doesn't
    understand.  Developers get frustrated because (1) they believe they
    should be able to do better, (2) it's hard to tell where the problem is,
    (3) it isn't clear how to tell CLIM anything that would help it's
    performance.

Yes, the stream-based model for dialogs has a lot of magic in it, and
it's hard to figure out what to do to make it faster.

    While programming in an X toolkit may be harder, at least some dialogs can
    be built by a GUI builder, and thus take almost no code at all.  Lisp and
    CLIM may be more maintainable ("habitable" is a word RPG uses).  But
    maintainablity, and portability for that matter, only counts if your
    project has a lifetime.  Also, if I have to pull a lot of tricks to get
    the CLIM performance I need, is CLIM helping?

I get good performance out of CLIM for many things, and rarely resort to
what can rightly be called tricks.  My suggestions to "implement your
own class of output record" really isn't trick either.  In most UI
systems, you would do this from day 0 of your project.  In CLIM, you use
the default implementation, and in the uncommon case where it is too
slow, then you have to do some more work.  But I think you still end up
doing less work that you would using most toolkits.

I am not trying to gloss over the fact that CLIM's performance is poorer
than good X applications.  But I don't know how to make it that fast.

    Lisp's vary, trust only the profiler.  It is nice to know that CMU CL can
    optimize certain things, and things work as one would expect on a LISPM.
    However, it doesn't help those of us who don't have those alteratives
    available.  LISPM don't cons floats or closures, and that's where I would
    guess lots of consing comes from in Lucid or Allegro.  It would be nice if
    CLIM's performance was more portable.

I agree.  Consing dynamic-extent closures on the stack is critical to
good performance in Lisp.

    Learn to make your Lisp/CLIM faster.  Share your knowledge with friends,
    as this email thread did.  Here's a hint nobody picked up.  The code
    fragment contained something like:

     if  <something> make-instance
     if <something-else> fill-instance using 6 generic function calls.

    If you could fill the slots when you make the instance, you save 6 gf
    calls.  Of course, this is not where your performance problem is.

CLIM has a trick for copying prototype instances for some things.  I
suppose I could post this code.

    Limits to generality.  CLIM tries to take the "right thing" approach.  It
    is so general, it will work on window system's nobody has seen yet.  X
    takes a more limited approach for which it is easier to guarrentee
    performance.  By stepping back from its generality goal we might be able
    to deliver higher performance on "average" Lisp's.  The example of &key
    and &rest args has been mentioned, here's another.  Coordinates are
    numbers in CLIM, lots (most?) of computation must be done using generic
    math.  An alternative might be to require floats or fixnum's at some level
    of CLIM might improve help.

Believe it or not, CLIM has a compile-time conditional that allows the
CLIM implementor to choose between three types of coordinates: T,
SINGLE-FLOAT, and FIXNUM.  Right now, CLIM uses T.  T and SINGLE-FLOAT
work equally well in Genera, but CER and I verified that using
SINGLE-FLOAT is a dog under Allero (and probably Lucid, too) because it
guarantees that you have to cons, whereas when CLIM uses T, CLIM often
manages to use fixnums.  CLIM 1.1 always used FIXNUM, but I never quite
finished debugging the FIXNUM case in CLIM 2.0.

    Of course, we're not going to redesign CLIM, now, except incrementally.
    But, we need to work together on these issues.  I think Gregor said, "the
    one thing you can't hide behind a layer of abstraction, is a performance
    problem".

Very true.  And Moon once said, "abstraction is the enemy of performance".
Follow-Ups:
Main Index | Thread Index