[PEAK] PEAK-Rules indexing performance

Alberto Valverde alberto at toscat.net
Fri Jan 9 07:03:17 EST 2009


We were struggling trying to optimize the bad performance (well, 
horrible: about 4 seconds just to build the tree the first time a gf was 
called with a different type signature) of a function heavily extended 
with peak.rules. Finally, an "intuition driven" optimization [1] hit the 
nail and performance improved *dramatically* (to < 0.1 s). This is the 
magic changeset:


Basically, some rules which were checking for set inclusion of an 
argument in a set bound to "self" were changed so the inclusion check 
was made against a list "inlined" into the same rule. Note that the 
performance improvement is not at runtime, the performance here is fine, 
but during the indexed tree building process when a gf is first called. 
The profiler reveals many, many calls to "implies" and "overrides". More 
details, wild guesses  and profiler output are here:


The thing is that we'd like to further optimize if possible following 
the same pattern or at least do it in a cleaner way. However, not 
knowing the real reasons doesn't make us feel too comfortable... So, 
please, can some light be shed over the reasons of this magical 
improvement? :)


[1] Since the only thing that came clear to us (well, sort of) from 
cProfile was that time was being spent inside peak.rule's tree building. 
Intuition and "lets try this" were our last last resort.

More information about the PEAK mailing list