launchpad developmentIt's easy to write a launchpadlib script by effectively treating launchpadlib as an ORM and Launchpad's web service as a data source. But the latency between your client and the Launchpad web service is much greater than the latency between your client and a database. This means it's easy to write a launchpadlib script that's very inefficient. Fortunately, by using a few simple diagnostics you can easily find the trouble spots in your application.
httplib2.debuglevel - the golden tool
The single most useful thing you can do to improve performance is to visualize the HTTP requests your client makes. The time spent making a network request dwarfs nearly any possible client-side processing you might do to the data returned from that request. So put the following code into your program, just before instantiating a Launchpad}} object or invoking {{{Launchpad.login_with():
httplib2.debuglevel = 1
Every HTTP request and the corresponding response will be printed to standard output. You don't need to understand what every single request does right away, but you should quickly be able to see which requests correspond to which lines of your code, and see whether the number of requests seems proportional to what you're trying to do.
Detailed examples
To see performance thinking applied to a large launchpadlib project, see these performance audits:
Performance audit for the Arsenal project.
Performance audit for the QA tagger scripts.
