Re: [Twisted-Python] Speed of rendering?
| 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