CLIM mail archive
[Prev][Next][Index][Thread]
Performance analysis of Clim incremental redisplay
Date: Thu, 7 Nov 1991 13:24 EST
From: Peter Karp <pkarp@ai.sri.com>
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.
bruce
miller@cam.nist.gov
0,,
Follow-Ups:
References:
Main Index |
Thread Index