Comment 2 for bug 740759

Some analysis. I believe nodes that are marked <module> mean the time is spent importing the module. This test was done without using the forking server, etc, so it probably has a bit of import time overhead that we will experience on production, but in theory the forking server helps with.

Of the 3.1s it spends to run lp-serve, there isn't a huge 'this is the problem' function. What I do see, are *lots* of <module> overhead.

1.268 <module> lp.codehosting.bzrutils
 .939 <module> lp.codehosting.vfs
 .938 <module> lp.codehosting.vfs.branchfs
 .832 <module> canonical.launchpad.webapp
 .831 <module> canonical.launchpad.webapp.launchpadform
 .801 <module> lp.app.browser.launchpadform
 .748 <module> canonical.launchpad.webapp.menu
 .675 <module> canonical.launchpad.webapp.authorization
 .641 <module> lp.codehosting
 .640 <module> canonical.config
 .469 <module> canoniacl.database.sqlbase
...

Once you are passed the imports, you get down into:
 .296 serve bzrlib.smart.medium:208
 .294 _getConfig canonical.config:192 (11 calls)
 .294 accept_bytes bzrlib.smart.protocol: 904

Looking at the top-down view,
1268 <module> lp.codehosting.bzrutils
 939 <module> lp.codehosting.vfs
 641 <module> lp.codehosting
 296 run_server bzrlib.plugins.lpserve:96

So we spend 1268+939+641 = 2.848s just importing the launchpad codebase to do the branch permissions, and only 296ms actually executing the request.

 .