Re: [Twisted-Python] Speed of rendering?

[email protected]
Newsgroups gmane.comp.python.twisted.web
Message-ID <20121024125924.4595.1178557312.divmod.xquotient.2@localhost6.localdomain6>


On 23 Oct, 03:10 pm, [email protected] 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.