CLIM mail archive


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

    Date: Mon, 20 Dec 1993 18:26 EST
    From: Jeff Morrill <jmorrill@BBN.COM>

    I can't resist commenting on this.

      Date: Mon, 20 Dec 1993 16:09 -0500
      From: Scott McKay <>

      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.

Actually, CLIM has a bunch of compiler macros that pick apart some of the common drawing
function idioms, and generate calls to functions that take position arguments.  It doesn't catch
everything, but it does part of the job.


	  Date: Mon, 20 Dec 1993 14:39 EST
	  From: Peter Karp <>

	  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.

My metering has always indicated that creating a presentation doesn't take any longer than I
expect given what it has to do.  That is not to say that there is no room for improvement, just
that there are no obvious things to tweak any more.

      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.

Yes, MEDIUM-DRAW-TEXT* on a medium is "simple".

    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.

Many floating point printers use bignums in order to retain precision when printing fractions
with lots of significant digits.  Genera keeps a table of bignums for this purpose, and doesn't
typically need to cons to do it.

    jeff morrill


Main Index | Thread Index