Doing profiling and performance tuning on a web application is normally a big pain. It's hard to profile things when processes (or threads) are always coming and going, and the typical web environment has so many sources of random delays that it is difficult to do fine-grained performance comparisons between two bits of code.

With WSGI, you can get out of this. Your WSGI application doesn't deal with the web directly, so you can write a WSGI frontend that is just a timing and profiling harness: it mocks up WSGI requests, fires them into your application, and discards the results. Unless your WSGI application itself forks or is threaded, profiling is easy, and in any case you can now time just your application instead of the entire system.

(This works in reverse, too; you can make up a 'null WSGI application' for when you are doing performance tuning on your WSGI frontend.)

The potential fly in this ointment is that your frontend needs to initialize your application somehow. Hopefully this is something you can extract from your usual WSGI framework.

My tuning frontend for DWiki is done this way; it's a command line program that I give a URL and how many requests to make, and it either profiles the run or tells me the time per request. It's quite convenient and easy to use, which makes it more likely that I'll bother to check the performance effects of code changes.

(Opinions may differ on whether this is a good thing; premature worrying about optimization is one of the roots of evil.)