July 2006 - mcclim-devel - mailman3.common-lisp.net

Re: Fwd: Re: [mcclim-devel] Severe performance regression with latest CVS sources?
by Christophe Rhodes 22 Nov '06

22 Nov '06

Paolo Amoroso <amoroso(a)mclink.it> writes: >> twice that many hash tables with (make-hash-table)? The other thing > > CL-USER> (time (dotimes (i (* 2 824)) > (make-hash-table))) > ; Compiling LAMBDA NIL: > ; Compiling Top-Level Form: > > ; Evaluation took: > ; 6,648 CPU cycles It's elided the creation, I'm afraid. Can you do (defvar *foo*) (time (dotimes (i (* 2 824)) (setq *foo* (make-hash-table)))) ? > ; > NIL > CL-USER> > > >> to look at is for collisions in your hash tables; check the EDGES-FROM >> slot of something with a lot of direct subclasses, say STRUCTURE-CLASS >> or CONDITION or NUMBER, and see if all of the entries are in the same >> bucket of the hash table) > > I'm not sure I understand what you mean. I used the SLIME inspector > to inspect the output of, say, (find-class 'structure-class). I > include the output below, which does not seem to have any EDGES-FROM > slot. I think the edges-from should be in the graph node output record. I'm not entirely sure how to get at one of those, but you could start by inspecting clim:*application-frame* from the slime inspector, finding the listener interactor pane, finding its output history, and looking at the output records in there. > 588,259,376 | 1,111 | 15.158 | 0.01364 | 529,486 | CLIM-INTERNALS::LAYOUT-EDGE-1 > 1,111: #<Code Object "LAMBDA (FWRAPPER)" {5A58260F}> > 1,470,608 | 2,222 | 0.056 | 0.00003 | 662 | CLIM-INTERNALS::ENSURE-EDGE-RECORD > 1,111: #<Code Object "DEFUN LAYOUT-EDGE" {59718A4F}> > 1,111: #<Code Object "DEFUN LAYOUT-EDGE-1" {5A75B007}> Well, that's moderately conclusive: the cost seems to be in LAYOUT-EDGE-1, not in ENSURE-EDGE-RECORD. Which is weird, because I can't really see what LAYOUT-EDGE-1 is doing that is so ludicrously expensive. Can you do the same thing, but with the CLIM package profiled additionally? (And then maybe one with CLIM but not CLIM-INTERNALS profiled?) The first 10 or so entries in each profile will probably suffice. (Maybe CLEAR-OUTPUT-RECORD is expensive?) Cheers, Christophe

3 3

[mcclim-devel] documentation fix
by Willem Broekema 24 Jul '06

24 Jul '06

Hi all, In file INSTALL there's 'asdf:load instead of 'asdf:load-op, and a missing closing bracket. This patch fixes that. - Willem

2 1

[mcclim-devel] CLIM-STREAM-PANE bugs mentioned in CLIM guided tour
by Paolo Amoroso 14 Jul '06

14 Jul '06

The version of the paper "A Guided Tour of CLIM" in McCLIM's source tree, which I believe is updated to early 2006, states in section "A simple drawing application": This is the first example that does not use clim-stream-pane (or one of its subclasses) as a pane class[*] [...] [*] When using McCLIM, we have to do this as there are bugs in the behavior of clim-stream-pane that have not been fixed yet. What are these bugs? Are they still outstanding? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

1 0

[mcclim-devel] Patch for menu-choose.lisp
by Troels Henriksen 09 Jul '06

09 Jul '06

The current implementation of `menu-choose' lacks a fair bunch of spec-defined functionality (labels, some menu item types, scrollbars), and it often creates menus that are larger than the screen, or partially off-screen. This patch rectifies these problems - I have been running with it for 6+ months and it has worked perfectly, even though some of the code is not the prettiest in the world (my CLIM-fu has been weak). There should be no functionality regressions compared to the current version. I know that McCLIM is currently in a freeze period, but this patch has been lying on my harddrive for too long - others may find it useful, and I would like it to be cleaned up (if necessary) so it could be included in some future release. :-) -- \ Troels "Athas" /\ Henriksen

8 12