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