Untwisting Python Network Programming
Subject:   Why untwisting?
Date:   2006-08-13 22:19:59
From:   Kendrew
Response to: Why untwisting?

Thank you for pointing out the possibility of TCP segmenting, which may cause problems to dataReceived.

Regarding performance, I observed the core modules runs faster than Twisted when running the programs. I also briefly did some measurements and here are the results:

Using core modules:
start server (no net): 0.6040 sec
send mails (smtp): 1.5585 sec
view mails (pop3): 0.7506 sec
delete mails (pop3): 0.5159 sec
stop server (telnet): 0.5063 sec

Using Twisted:
start server (no net): 0.6668 sec
send mails (smtp): 2.4919 sec
view mails (pop3): 1.4418 sec
delete mails (pop3): 1.2992 sec
stop server (telnet): 2.1045 sec

(Windows XP, Python 2.4.3, Twisted 2.4.0)

These numbers are the average of 10 runs, and the mail server is run in localhost. While the measurements are by no means vigorous, they basically agree with the observations. Of course, the differences may not be significant in real uses when the network delay counts for majority of the execution time.

Main Topics Oldest First

Showing messages 1 through 2 of 2.

  • performance
    2006-08-14 08:16:53  radix [View]

    How were these numbers reached? Can you show us any python code or commands that you used to find them?

    I notice that your synchronous version of the telnet code immediately closes the socket whereas the twisted version is waiting for the *server* to end the connection; this could definitely be affecting your times. If you add a transport.loseConnection call after your write call, the semantics should line up better, and I imagine performance will be closer to what we expect.

    Also, why are you calling the private "_write" method in the telnet example?
  • Why untwisting?
    2006-08-14 08:15:01 [View]

    Are you measuring the time it takes to perform a task, or the amount of time it takes to start the interpreter, load every module, perform the task, and shut down the interpreter?

    Twisted has more code in it than the Python standard library version, so unless you've carefully optimized the package for importing, the amount of time spent loading code will dwarf the amount of time spent actually doing anything.