CLIM mail archive


reducing time overhead of text display (in 1.1)

    Date: Sat, 18 Dec 1993 15:25 EST
    From: Daniel D Suthers <>

    Clim 1.1 in Lucid (and MCL2.0 occasionally)

    We've been having serious performance problems with the display of
    long texts in CLIM. At first, suspecting that indenting output and
    formatting output were individually or collectively to blame, I wrote
    my own indenting&formatting code for writing strings. However, the
    only advantage seems to be that my code displays incrementally -- it
    still takes about as long (subjectively) to complete the process.  So
    I timed my indenting&formatting function writing to the lisp listener

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.

      Elapsed Real Time = 4.86 seconds
      Total Run Time    = 1.95 seconds
      User Run Time     = 1.44 seconds
      System Run Time   = 0.52 seconds
      Process Page Faults    =          7
      Dynamic Bytes Consed   =          0
      Ephemeral Bytes Consed =    850,176
      There was 1 ephemeral GC

    and writing into the main display of our application-frame:

      Elapsed Real Time = 6.88 seconds
      Total Run Time    = 6.73 seconds
      User Run Time     = 5.61 seconds
      System Run Time   = 1.12 seconds
      Process Page Faults    =          6
      Dynamic Bytes Consed   =          0
      Ephemeral Bytes Consed =    962,896
      There was 1 ephemeral GC

    The difference in total run time makes me wonder: what overhead is
    associated with writing strings into CLIM streams and how can I
    minimize it?

The difference in run time is about 30%, and (presuming that the first
set of numbers reflects doing output *not* in a CLIM window) that's
pretty reasonable (although not brilliant) considering that you are
getting output recording.  Note that 110K more bytes were consed,
presumably all CLIM output records.

    Unfortunately the above is not the bulk of the problem. The above
    writes did not involve any presentations, but most of our texts are
    segmented into dozens (or more) of nested parts that each require a
    presentation. If I write the segmented version of this string it takes
    longer. For example, the stats for a text of similar character length
    but highly segmented are:

      Elapsed Real Time = 26.48 seconds
      Total Run Time    = 26.21 seconds
      User Run Time     = 19.24 seconds
      System Run Time   = 6.97 seconds
      Process Page Faults    =         12
      Dynamic Bytes Consed   =          0
      Ephemeral Bytes Consed =  2,972,208
      There were 6 ephemeral GCs

Here is where CLIM is clearly doing very badly for you.  It's consed 2
*million* more bytes of stuff, which means you must have an awful lot of
presentations.  My advice (in increasing order of important) is to (1)
figure out where the first 850K bytes are coming from, and (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.

    So our users have to wait half a minute every time they modify the
    text (or something in the same pane)! Any comments on reducing the
    overhead of creating presentations from the CLIM end of things? (We
    will of course continue to scrutinize our own code.)

Believe it or not, creating CLIM presentations is actually not really
that expensive, but there is a cost.  Your application seems to be off
spending 25cents about a million times, which starts to add up.

     Dan Suthers           | LRDC, room 505A     | 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