[PEAK] PEAK-Rules indexing performance

[Phillip J. Eby]

At 09:12 PM 1/9/2009 +0100, Alberto Valverde wrote:
>All those 13.7 seconds in build_leaf are for a couple of call to the 
>same GF with arguments of different types. Unfortunately they all 
>occur in the same request the first time certain views are called 
>(hence the urgent need to optimize it)

Interesting.  Oh yes, "truth" nodes eagerly build their subtrees, 
because they always have only two nodes.  So what's happening is 
you're getting the blowup in the eager portion of the tree 
builds...  which explains why truth_node() is 19+ 
seconds.  (truth_node is the function that builds out a yes/no branch 
in the dispatch tree, and it immediately builds out both its sub-nodes.)

In fact, now that I look more closely at the code, I see the *only* 
node type that's lazily built is type dispatches.  So the behavior 
you're seeing makes a bit more sense to me now.  Each time you hit it 
with a new type, it then ends up building out the entire subtree 
underneath that type.


>>In the long run, I'd like to handle the sort of use case you're 
>>doing by allowing "predicate functions" to exist; then you could 
>>define a GF like 'is_edit_action(ob, action)', and thus be able to 
>>redefine the edit actions for a given class, but still get the 
>>optimization benefits.  The idea is that the predicate function 
>>would be expanded into its full logical form inside the tree 
>>building of the outer function.
>
>Hmm, sort of like "generic meta-functions"?

Yep, basically.  The main difference being that, unlike the 
meta-functions, they'd be dynamically updatable.


>After some peeking at peak.rules internals, motivated by the meta 
>function recipe you posted some months ago to optimize the "isclass" 
>test, I thought about using them to simplify some rules by 
>"wrapping" several related checks under a function without incurring 
>in performance penalties due to non-statically analyzable predicates.

You can't really do that; meta-functions have to expand back into 
statically-analyzable predicates, and so will these "predicate 
functions".  Essentially, both meta-functions are like macros, and 
predicate functions will be like macros that take effect at runtime 
instead of compile time.  ;-)