[climacs-devel] Any tips on making the Climacs GUI more responsive?

[Christophe Rhodes]

Paolo Amoroso <amoroso at mclink.it> writes:

> Sean Champ <gimmal at gmail.com> writes:
>> While I mean no affront on this, but to address the matter in attempte at
>> accuracy: I am not certain if it may be a matter contingent as on CLIM and
>> the CLIM implementation. (Considering: At the stuff about coordinate-system
>> adjustment in CLIM, and while I know that is but one part to the CLIM
>> standard, and I do not know how crucial that it is to the rendering of the
>> Climacs GUI, but I wonder if it might, in however, serve as to occasion any
>> lag of the visual interface.)
>
> Within the past few months there has been a McCLIM performance
> regression: drawing a very large class graph with the CLIM Listener
> takes about 15X longer than it used to.  With guidance from Christophe
> Rhodes I did some benchmarking and tried to locate the possible cause,
> but I didn't get any useful results.

I thought we established that this was because McCLIM now creates
output records for arcs, to support repositioning nodes and having the
arcs in a graph redraw themselves (as in the graph drag and drop
demo)?

> I don't know whether your Climacs responsiveness problems are related
> to this.

I doubt it.  One factor that does matter, at least to first startup,
is the fact that generic functions are generated (when a defgeneric or
defmethod is loaded from a fasl file) in a pristine state, with no
information about any effective methods, which are generated on
demand.  Since McCLIM is extremely CLOS-heavy (using generic functions
in all layers of the various protocols), at application startup many,
many generic functions are run for the first time, at which point lots
of caches are generated, activated and filled.  To see this effect,
measure the time to start climacs up from a clean load, close it, and
start climacs again.

>> [1] I'm using a recent build of X.org from debian/sid, and the recent
>> Common Lisp sources for the components to CLIM, running in SBCL 0.9.11
>
> You might try using CMUCL instead.  A few years ago CMUCL produced
> code twice as fast as SBCL's.  SBCL has been greatly improved since
> then, but on your slow machine using CMUCL might still make a
> difference.

For what it's worth, I consider this unlikely.

Cheers,

Christophe