CLIM mail archive


Performance analysis of Clim incremental redisplay

    Date: Thu, 7 Nov 1991 13:24 EST
    From: Peter Karp <>

    I have lately been analyzing the performance of a CLIM application
    under Lucid CLIM 1.0-Beta on a Sparc 1+, and I thought members of this
    list might be interested in the results.

    Graph size:				100	200	400	800
    Incremental redisplay:		8	26	97	351
    Updating-output full display:	21	57	180	595
    Simple full display:		15	32	86	234

    I will note in closing that I have been able to speed up the simple
    full display by a factor of 3-4 by optimizing my code by hand and in
    conjunction with Lucid's optimizing compiler.  Presumably these
    optimizations will not affect the incremental redisplay since my code
    is only being executed for the single changed node during incremental
    redisplay; the majority of the computation must be internal to CLIM.

    Peter Karp

Just to clarify a minor point with the tenses:  The table displays the
numbers for simple full display _using_ your optimized code?  Or you were
_later_ able to optimize?

My point is that an important idea of incremental redisplay is to
minimize the amount of drawing that is done.  If the drawing took an
infinitesimal amount of time, other than flicker, there would be no
reason to use incremental redisplay.   Perhaps it is best for a `quick'
fix for quickly written drawing code?  As you optimize the drawing, you shift
the tradeoff point.

The non-linearity is interesting.  Determining what has changed should
be linear.  Does the non-linearity come from determining what, if
anything, is overlapped by a changed display object?  
Is this the context for mentions I've seen for fancy datastructures in CLIM?
Ie. that they (more) quickly deterimine what objects are at <x,y> ?

Anyhow, thanks Peter; quite interesting.


Follow-Ups: References:

Main Index | Thread Index