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