On Apr 27, 2010, at 9:49 AM, Jean Daniel wrote:

> Hello,

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@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Reply via email to