[Twisted-Python] GUI responsiveness

[glyph at divmod.com]

On Wed, 14 Sep 2005 13:35:35 +0200, Antoine Pitrou <solipsis at pitrou.net> wrote:

>Never tried GTK with Twisted, but I don't understand how you can say
>that generally.

I was saying it was easier to program, not that it performed better (and by the way, it *does* perform better than WX), but since you asked -

>Suppose a network event is taking some time to process (e.g. the
>protocol is complex and there are some calculations involved), then your
>GUI will become unresponsive (a 100ms delay is not critical for most
>Internet protocols, but it is for GUIs).

Not at all.  A user clicks on a button; if they don't see an update for 100ms, that is barely enough time for them to flick their mouse over to another button.  In fact, network latency is such that it is nearly impossible to provide faster than 100ms actual real response time even for highly performance-critical applications.

If the UI isn't redrawing for 100ms, it is hard for the user to even notice, unless it is a continuous 100ms between redraws, in which case this GUI application is really doing quite a lot of work!

>Suppose there are lots of network events coming in, which flood the
>event loop for a short time. When will GUI events be processed ? Again,
>a 100ms delay will feel very annoying for the user (and more than 1
>second delay is awful).

A news aggregator I use, straw, does blocking DNS lookups and can hang completely for upwards of a minute while it's doing an update.  While this is not exactly ideal behavior, it's tolerable.  Even Firefox locks up for a few seconds when rendering a complex page.  You are somewhat overstating the case - I sure wish that everything were faster, but 100ms latency on certain operations is not going to make anyone stop using an application :).

>On the other hand, if you have one thread for networking and one thread
>for the GUI, the OS can take care of the scheduling priorities
>naturally, using its sophisticated builtin mechanisms (e.g. noticing
>that one thread is "interactive" while the other is not), so you don't
>have to rewrite/emulate/composate for the lack of/ them.

>Am I missing something here ?

A few things:

1 - this is really not as major a problem as you say, for the reasons given above.
2 - this argument is tangential; if the thread scheduler is so sophisticated, it will notice that the IO-plus-UI thread is also "interactive" and schedule it appropriately.  (In fact, both threads in your example are "interactive" according to Linux 2.6's scheduler heuristic, I think)
3 - you don't have to emulate anything about threads when writing Twisted GUI applications unless you have extremely computation-intensive actions to perform; and in that case you can use threads for those (few) actions rather than everything in the app
4 - you're assuming that you have to build extra to "compensate" for the lack of threads, but you're ignoring the cost of building support tools to use them.  building thread safety into even a single API is difficult, costly, and extremely hard to test for correctness even superficially.  
5 - if you have a networked interactive application under high load, you are not going to improve performance or interactivity by performing a ton of additional context switches as well as a bunch of extra work locking and unlocking shared mutexes.  smart as the scheduler is, your computer *does* only have one or two processors, and more threads = more work.  (this is especially true if you are using threads for EVERYTHING in your application, rather than just the truly parallelizeable tasks)
6 - in Python, your threaded work has to release the GIL to give any substantive improvement in performance, which it probably doesn't.

... and that's just off the top of my head.