On 23 Oct, 03:10 pm, peter.westlake@pobox.com wrote:
On Tue, Sep 4, 2012, at 19:30, Glyph wrote:
...
Not only is there a profiler, there's benchmarks!
<http://speed.twistedmatrix.com/timeline/>
Maybe you could add one for twisted.web.template rendering speed?
Okay, I've found out how to use the profiler (though I never did find out what I did wrong the first time) and I'm reading the docs about how to interpret the results. The benchmark code doesn't look as though it uses the profiler, just times a number of repetitions - is that right? So a benchmark for t.w.template would consist of some functions that called flatten() once each?
That's the general idea, yes. Of course, each benchmark should try to be vaguely representative of some real-world use-case so that we don't optimize one case too much in favor of another.
Glyph,
I haven't forgotten about this. The problem I'm having is that flatten() returns immediately if given a string or anything else without an unfired Deferred, and that sends Client._continue into an unbounded recursion. Is there a general good way to handle this kind of problem? Somehow I need to return control to the reactor long enough for Client._request to return.
The benchmark tools are really intended for actually asynchronous things, like setting up a TCP connection. They can be abused into testing synchronous things, but the results are not very good. It would probably be better not to try to re-use the asynchronous testing tools for testing synchronous APIs and instead build some tools for testing synchronous APIs. These should be simpler anyway. You don't *need* a running reactor for the synchronous case of flatten(). Jean-Paul