CPU cycles. It's called once for each builder, every time the console is generated. For us, collectively those invocations take about 0.8 seconds to run, which accounts for about 80% of the time required to build the console. Since the return values change pretty infrequently, it should be possible to cache the results and speed up subsequent lookups.

We use an SVNPoller with a polling interval of 10 seconds. In svnpoller.py, parse_logs() accounts for 8% of CPU cycles, and takes 0.8 seconds per invocation (each time the poller runs). 99% of that time is spent in xml.dom.minidom.parseString(). It should be possible to speed that up by either switching to a faster xml parser; or *not* using the --xml option to svn log and custom parsing the output.

getBuildsForRevision will go away in nine, so I'm not too worried about that.

However, the SVNPoller problem could be fixed. The simplest solution is probably to defer the XML parsing to a thread. That gets UI responsiveness, and may get some parallelism depending on how friendly parseString is to the GIL.