CLIM mail archive
Re: reducing time overhead of text display (in 1.1)
Date: Wed, 22 Dec 1993 11:51 EST
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
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
Very true. And Moon once said, "abstraction is the enemy of performance".
Main Index |