[Twisted-web] [Twisted-Python] Speed of rendering?

[exarkun at twistedmatrix.com]

On 23 Oct, 03:10 pm, peter.westlake at 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