Re: Severe performance regression with latest CVS sources?

Robert Strandh <strandh@xxxxxxxx> 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