[Twisted-Python] draft of an article on Twisted
jeandaniel.browne at gmail.com
Thu Apr 29 17:13:41 EDT 2010
thanks for your feedback, it helps.
On Thu, Apr 29, 2010 at 12:06 AM, Glyph Lefkowitz
<glyph at twistedmatrix.com> wrote:
> On Apr 27, 2010, at 9:49 AM, Jean Daniel wrote:
> Hi Jean!
> I have written an introductory article to Twisted, and I would be
> delighted to see it published on Linux Weekly News some day.
> It is available at: http://jdb.github.com/concurrent.html
> Wow. This is an incredible, sprawling article :).
> I'm glad you wrote it, and I think it introduces quite a bit of material.
> I don't really have time to write up a full editorial review, but definitely
> the strongest impression I got from reading it was this comment which you
> already made:
> - it might be too long and present too many things, maybe I should split it
> in parts,
> This is really a series of articles; you should expand on each part, one at
> a time. It really seems like you're rushing through it in order to cover a
> lot of ground.
> Someone who is deeply committed to learning about Twisted and is planning to
> spend quite a while reading it would be well-served by your introduction.
> However, most people who come to Twisted are actively trying to get
> something done, and they don't care about the theory too much until they
> manage to get some basic stuff working. So you may want to provide some
> more pointers to tutorials and other practical getting-started guides.
> You also focus a bit too much on performance. While a Twisted server does
> provide some performance benefits, it's very hard to conclusively measure
> that one approach is really "faster" than the other; especially since some
> Twisted idioms (such as the inlineCallbacks example at the bottom of your
> article) are just as "slow".
> There are lots of benchmarks showing various different performance
> characteristics of multithreaded vs. multiprocess vs. event-driven code, and
> with modern optimizations in each of these architectures, which of these is
> really the fastest changes from year to year. If you were to take some
> benchmarks of Twisted vs. code using the 'multiprocessing' module, for
> example, you might get some surprising results (and ones which would vary
> wildly depending on which platform you were using and what exact algorithms
> you used in each example).
> If you want to focus on performance, you should include benchmarks and
> measurements which back up your claims. Personally, I'd focus more on the
> safety and comprehensibility discussion. Even in the realm of performance,
> the issue isn't that Twisted is really *faster*, per se, it's that the
> structure of the code is easy to understand and modify, and therefore easier
> to optimize when you know what your bottlenecks really are. My favorite
> example of this is "try to write a failing unit test for a race condition in
> multithreaded code". In most Twisted applications, you can force the order
> of execution in your test so that you can verify the race going one way,
> then the other, but with threads it's very, very tricky (and sometimes not
> really feasible, or even possible).
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
More information about the Twisted-Python