[PEAK] PEAK-Rules indexing performance
Phillip J. Eby
pje at telecommunity.com
Fri Jan 9 18:37:08 EST 2009
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. ;-)
More information about the PEAK