thanks for your feedback, it helps.
On Thu, Apr 29, 2010 at 12:06 AM, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: > > 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 > > _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
