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
