CLIM mail archive
Re: reducing time overhead of text display (in 1.1)
To: kanderso@BBN.COM, SWM@stony-brook.scrc.symbolics.com, clim@BBN.COM,
Subject: reducing time overhead of text display (in 1.1)
From: "Albert G. Boulanger" <aboulanger@BBN.COM>
Date: Wed, 22 Dec 93 14:50:51 EST
Ken quotes Gregor:
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
Well, this is my quote of the day!
Seriously, I do not think that this quote is totally true. I am a bit
surprised that nobody is making use of lisp's abstraction power to
*leverage* efficiency. Yes, one would like a environment like Clim
Well, people like Gregor are. The idea behind the MOP is to provide
flexibility, abstraction, and performance. Xerox's recent work in compile
time MOP's is very interesting.
where the programmer cost of doing some fairly hairy GUI stuff is
easy, but the code has little *explicit* representation of the notions
of development cycle vs use cycle. Now, if one had to choose a
language for doing such an explicit representation, would Lisp not be
high on one's list of choices? What I am saying is that one can hide
performance issues of development cycle with abstraction. But the
there is an onus for good user cycle performance on the GUI
infracstructure at the end. This infracstructure support for
performance may need something as radical as Dylan, but I think we can
do things to help our *current* Lisp situation.
In a lot of ways, this train of thought has lead me to be interested
in building Lisp-base re-engineering tools for languages -- including
dusty-deck Fortran code. This is an area where some of the performance
issues discussed can be well separated without a lot of major
infracstructure development for Lisp itself, but still utilizing
Lisp's power of abstraction.
Once I know how to spit out high-performance re-engineered Fortran or
C code, I can begin to take the lessons learned and apply them to Lisp
I have an interesting paper by Richard Fateman and others, "Fast
Floating-Point Processing in Common Lisp". It not only talks about Lisp
performance, but describes a Fortran -> Lisp translator.
Main Index |