[mcclim-devel] Severe performance regression with latest CVS sources?
Christophe Rhodes
csr21 at cam.ac.uk
Mon Apr 10 18:46:50 UTC 2006
Robert Strandh <strandh at labri.fr> writes:
> Hello,
>
> Paolo Amoroso writes:
> > When I update my working copy of McCLIM's CVS sources, I do a quick
> > test to check that things still work fine. I run the CLIM Listener
> > and evaluate a form that draws a monster graph:
> >
> > (time (clim-listener::com-show-class-subclasses t))
> >
> > Until a few weeks ago, I got run times under 1 s (I seem to remember
> > about 0.7-0.8 s) with CMUCL under Slackware Linux 10.0. With the
> > latest McCLIM CVS sources and CMUCL Snapshot 2006-02 (19C), I now get
> > times over 15 s, no matter whether I initialize multiprocessing with
> > (mp::startup-idle-and-top-level-loops) or not.
> >
> > Can anybody confirm this?
>
> Most likely you have run into the same problem I did with Gsharp,
> namely that output-record creation is now slower with tree-structured
> output records. You should be able to ask for a sequence output
> record, or you can do what I did with Gsharp, namely organize the
> output records into smaller hierarchical units.
I would be surprised to find this kind of performance regression for
such a simple test (which, furthermore, is probably dominated by the
cost of computing the graph layout); I think that Andy and Andreas
measured the slowdown from inserting tree output records as a
relatively small multiple for about 10000 output records -- not a
factor of 20. Admittedly I still haven't optimized the spatial trees
for two-dimensions, nor even removed the debugging
ordering-constraint-checking code.
Be that as it may, rather than speculating further I would suggest to
Paolo that he try with the mcclim sources of "a few weeks ago" in the
same lisp and compares the results. If there is a difference, then
bisecting the cvs checkins should find the offending commit in a small
amount of time.
Cheers,
Christophe
More information about the mcclim-devel
mailing list