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

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


I can't resist commenting on this.
  
==================

  Date: Mon, 20 Dec 1993 16:09 -0500
  From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>

  So with the above in mind, here's a brief answer, with some comparisons
  thrown in against C/C++ as well.
  
   - If you're using C or C++, you are using a language most of whose
     compilers produce good code with almost no function calling overhead.
     When you are doing lots of function calling, C still beats Lisp every
     time.  CLIM does a lot of function calling.

Actually, Lisp and C are pretty equivalent when it comes
to the amount of time required for one function call  (.5 microseconds
on a Sparc).  Where C wins big is that some optimizing compilers will in-line
virtually everything and eliminate the function calls altogether.
  
   - Method dispatching in CLOS has to be done completely at run-time.  It
     can often be done with no overhead in C++.

Yes, C++ method dispatching is often compiled into a function call.
Often, C++ programs have no run-time dispatching.  (C++ is virtually an
object-oriented language!)

Don't forget that clim uses &rest and &key profusely.  These are inherently
slow and should have been avoided for operations that are supposedly efficent.
For example, every time I call DRAW-LINE*, clim has to take apart all those
keywords just in case I want dotted lines (even though I never do).  Using
&rest or &key increases the cost of a function call by as much as an
order of magnitude.

==================

      Date: Mon, 20 Dec 1993 14:39 EST
      From: Peter Karp <pkarp@ai.sri.com>

      Believe me, I appreciate CLIM's high-level capabilities or I wouldn't
      be using it.  But I believe that a measure of high-level snottiness
      has gotten in the way of getting CLIM to do simple things quickly.

I don't think we should define presentations as "simple things."
Generating one presentation should take an amount of time equivalent
to calling MAKE-INSTANCE plus inserting it into a sorted output history
plus capturing all the devious things you can do with the WITH-xxx macros.
These things are unavoidable.  If it takes longer than this, then
perhaps we have something to complain about.

==================
  
  It should come as no great surprise that calling MEDIUM-DRAW-TEXT* on
  the medium (rather than the sheet or stream) is *much* faster than
  calling DRAW-TEXT* and doing output recording.

MEDIUM-DRAW-TEXT* is what I call a "simple thing".  Drawing a character
(or a string) with no output recording should be fast.  I benchmarked DRAW-CHAR
at 9 microseconds for file I/O.  I don't know what it would be for a window,
but presumably it is nearly as fast and doesn't cons.

Note however that PRINT can be a real dog, even without output recording.
Printing a floating-point number typically takes around 1000 times
longer than printing it's component characters.  This is because of the
bignums that get consed figure out which digit comes next.  (Bignums?!)
CLIM implementors didn't write these horrid algorithms, but it can be a
factor in the user's impression of clim performance.

jeff morrill
jmorrill@bbn.com
Follow-Ups: References:
Main Index | Thread Index