PEAK-Rules indexing performance
Alberto Valverde <[email protected]> Fri, 09 Jan 2009 13:03:17 +0100
| Newsgroups | gmane.comp.python.peak |
|---|---|
| Message-ID | <[email protected]> |
Hi, 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: http://hg.python-rum.org/tw.rum-exp/rev/1446664f1423 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: http://python-rum.org/ticket/53 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? :) Cheers, Alberto [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.