[cells-devel] Cells stats just posted to CLL under "I never did this before"

[Ken Tilton]

Traversed a real world (look it up) Cells model (pretty much a control 
bar, two list boxes with a total of less than 20 items, then a display 
of sixteen algebra problems with <gasp> each algebraic node implemented 
by its own model (cells-powered class) instance) [such that 2+4 would be 
four clos instances counting a top-level container I use] culling stats:

Surprisingly few instances: 438, and a little more than half of those to 
cover the math nodes. Hmm, just realized that might make this model 
unrepresentative -- or will any big, realistic model involve half the 
instances being from one small but vital subtree of the overall OO 
hierarchy?

As predicted, the silver bullet: an average of 1-2 (I had guessed 2-3, 
but on reflection that sounds right) dependencies per ruled cell (the 
silver bullet being natural decomposition of what Brooks took to be 
ineluctable (his word was "intrinsic") complexity arising from 
exponentially climbing interdependence as kinds of states grew).

Cells created: 7000
Ruled cells: 5800
Input cells: 1200, a shocker, but 1000 are kludges to avoid insane 
dependency on the mouse position that is trivial to handle imperatively 
(well, by an observer on the mouse position cell) and another hundred 
are similarly multitudes of OS-event hooks used so not everyone ends up 
sitting there waiting on (and processing) every click event.

Ruled cells optimized away (no dependencies found): 2000

No surprise there, always had big savings from cell optimization.

Intriguing histogram of length of dependency chain (ignore column one, 
my trace function does something with real time):

time     count    length of dependency chain
18569 ...  1 ... (:DEP-DEPTH 39)
18570 ...  1 ... (:DEP-DEPTH 40)
18572 ...  2 ... (:DEP-DEPTH 36)
18575 ...  3 ... (:DEP-DEPTH 35)
18578 ...  3 ... (:DEP-DEPTH 41)
18586 ...  8 ... (:DEP-DEPTH 22)
18594 ...  8 ... (:DEP-DEPTH 25)
18602 ...  8 ... (:DEP-DEPTH 28)
18610 ...  8 ... (:DEP-DEPTH 31)
18618 ...  8 ... (:DEP-DEPTH 30)
18635 ... 17 ... (:DEP-DEPTH 34)
18655 ... 20 ... (:DEP-DEPTH 21)
18677 ... 22 ... (:DEP-DEPTH 18)
18699 ... 22 ... (:DEP-DEPTH 37)
18723 ... 24 ... (:DEP-DEPTH 33)
18751 ... 28 ... (:DEP-DEPTH 27)
18787 ... 36 ... (:DEP-DEPTH 24)
18843 ... 56 ... (:DEP-DEPTH 32)
18903 ... 60 ... (:DEP-DEPTH 17)
18964 ... 61 ... (:DEP-DEPTH 15)
19029 ... 65 ... (:DEP-DEPTH 38)
19094 ... 65 ... (:DEP-DEPTH 12)
19172 ... 78 ... (:DEP-DEPTH 19)
19251 ... 79 ... (:DEP-DEPTH 9)
19331 ... 80 ... (:DEP-DEPTH 14)
19413 ... 82 ... (:DEP-DEPTH 20)
19501 ... 88 ... (:DEP-DEPTH 23)
19591 ... 90 ... (:DEP-DEPTH 29)
19683 ... 92 ... (:DEP-DEPTH 26)
19811 ... 128 ... (:DEP-DEPTH 6)
19997 ... 186 ... (:DEP-DEPTH 11)
20214 ... 217 ... (:DEP-DEPTH 16)
20524 ... 310 ... (:DEP-DEPTH 8)
20921 ... 397 ... (:DEP-DEPTH 13)
21329 ... 408 ... (:DEP-DEPTH 5)
21936 ... 607 ... (:DEP-DEPTH 10)
22553 ... 617 ... (:DEP-DEPTH 4)
23295 ... 742 ... (:DEP-DEPTH 7)
24101 ... 806 ... (:DEP-DEPTH 3)
27277 ... 3176 ... (:DEP-DEPTH 2)

I like the outliers at some of the depths, again probably because of the 
(unusual?) distribution of instance classes. Anyway...

Maximum dependency chain is 41 which is kinda inconceivable to me (who 
was strangely too lazy to print the chain out-- well, I actually was 
gunshy because of a fascinating problem here: traversing the dependency 
graph "the other way" (from user to used) was computationally 
ridiculous! I had to do some memoizing! Yet going the other way 
(propagating from basically OS event forward to dependents) is crazy 
fast. Clearly a Message From God, just not sure what. Anyway...) I mean, 
yeah, it (the chain of 41) is GUI-geometry related and I guess comes 
from the position of some high-level container being dependent 
(eventually) on the font metrics of the denominator of the fraction in 
the product in the sum on the right side of the equation... Buddha 
covered this, the universe being one vast web of cause and effect 
amongst universally interconnected stuff -- anyway, looks like some 
simple lockdowns could reduce that a lot, but the app is pretty snappy 
as is.

Calling up the sixteen problems (going from a list item not implemented 
so it shows zero problems) shows that cost in isolation (timing columen 
deleted this time):

308 ... (:MD-AWAKEN)

Those are new model instances coming to life, mostly math

2321 ... (:C-AWAKEN)

Cells needed by those instances to mediate their slots. Again, probably 
900 low-functionality input cells as an optimization trick.

5927 ... (:MD-INSTALL-CELL)

Hang on, that is the real cell count. Oh, OK. the count :c-awaken gets 
hit during md-awaken only if a scan of the slots of a new instance finds 
a nascent cell. Cells can be awakened JIT if some other new cell asks 
for them and this happens roughly 3606/5927th of the time.

665 ... (:C-OPTIMIZED)

Take away the input cells (they cannot be optimized away) and we are 
looking at 40% optimization of ruled Cells into fixed values.

3911 ... (:CPROPAGATE)
16148 ... (:ENSURE-VALUE-IS-CURRENT)

That be the dataflow. Lots of ensure current, but you wanted data 
integrity, right?

kt