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

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

----------
In reference to my comparison of "listener":
      Total Run Time    = 1.95 seconds
      Ephemeral Bytes Consed =    850,176
vs. CLIM application pane:
      Total Run Time    = 6.73 seconds
      Ephemeral Bytes Consed =    962,896
Scott asks:

> Is this a CLIM Lisp Listener, or the Lucid Lisp Listener?  If it's not a
> Listener that's doing output recording, then those 850K bytes are pretty
> suspicious.  If it's not a CLIM Listener, who's doing all the consing?
> That's probably where a lot of your time is going.

It was the Lucid lisp listener. I don't know where the consing is, will
investigate.

----------
> (2) write a
> new kind of output record that stores knows about the kind of data you
> are presenting, and creates and caches presentations at the moment they
> are needed (as the user is waving the mouse around), not when you are
> doing output.  This will make mouse tracking very slightly slower, but
> it will amortize the cost of their creation across a much greater period
> of time.

We already have this information in a clos object that is stored as the
:object of the presentation, so it may not be hard, but I don't know
CLIM well enough to know where to begin ... put that on the learning
queue.

----------
In reference to my macroexpansion ...
> In the code above, what is the call to UPDATING-OUTPUT for?  It doesn't
> supply either a unique-id or a cache-value, so that would normally mean
> that it is the *outermost* call in redisplay.  But nothing inside it is
> an updating output record.  And it surely doesn't add any information
> that CLIM can use.  My advice?  If you don't need it, flush it -- it's
> *doubling* the number of output records you are creating.

> If you are calling REDISPLAY on (OUTPUT-RECORD DISPLAY-OBJECT) objects,
> then I guess you'll have to keep it, but it still seems very odd that
> there are neither lower-level calls to UPDATING-OUTPUT nor a unique-id
> or cache-value.

* The macro is wrapped around various kinds of display code, some of
which is top level and some of which is not, and some of which does have
nested presentations ... Clearly we need to specialize the macro!

* Yes we call redisplay on (output-record display-object). This is our
initial and incomplete attempt at incremental redisplay -- it does not
work yet, so don't make strong inferences from the lack of cache values! 

The displayed object is a CLOS instance (actually a mixed CLOS/LOOM
object). Redisplay would be necessary if any of a number of slots
(including LOOM roles) changed their values, but is not necessary for
all changed slots. I presume this means we need to use :cache-test.

----------
> WITH-END-OF-PAGE-ACTION and WITH-END-OF-LINE-ACTION are not free.  
> Hoist them out to a higher level.

Thanks, that saved a second or two. I already had it at top level, guess
these were just "leftovers."

Well, that sure generated some discussion...

--------------------------------------------------
 Dan Suthers           | LRDC, room 505A
 suthers+@pitt.edu     | 3939 O'Hara Street
 (412) 624-7036 office | University of Pittsburgh
 (412) 624-9149 fax    | Pittsburgh, PA 15260
--------------------------------------------------
Follow-Ups: References:
Main Index | Thread Index