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

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


A few comments on this thread.  I'm not going to metion any names to keep
it shorter, so you all get full credit for your contributions, thanks.

Fustration with the magic.  I highly recommend Dick Gabriel's
"Critic-at-Large" columns in the Journal of Object Oriented Programming.
Much of what the columns say are entertaining and relevant to this
discussion.  For example, here are some hard words:

"... the market place does not care how much it costs a company to produce
a software product -- what customers really care about is price and speed.
...  The CEO is a fool who saves money on development by using a language
with high productivity and (necessarily) poor performance." [JOOP,
July-August '93, p. 92]

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.

However, what the user sees is a dialog box, like he sees in other
applications.  The user is fustrated when the application feels a little
slow, or worse pieces of it are unusable.  Management gets fustrated, and
blames "CLIM" or "Lisp" because it is easy to blame things one doesn't
understand.  Developers get fustrated 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.

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?

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.

CLOS speed.  Lisp and C funcall roughly at the same speed (it varies
depending on optimization settings, and yes C probably wins at the higher
settings, but they are reasonably comparable).

Here are some rough numbers [i have benchmarks to support this.]

Funcalls Operation
  4      Single dispatch generic function
  3.5    Reader method
 22      Single dispatch with around method  (GROSS!)
 17      Make-instance Lucid (61 Allegro)
  3      First slot-value method, Lucid (3.4 Allegro)
  0.5    Second slot-value in method, Lucid (2.2 Allegro)

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.

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. 

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

k
References:
Main Index | Thread Index