Paolo Amoroso amoroso@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