So Andrew put together lp:~spiv/launchpad/codehosting-cheaper-failures, and I did some tracing, and found one more case where we were creating a deferred that always used the default Failure handling. Putting together those patches, I did a bit more perf testing. The following numbers are running 'initialize' multiple times (deleting the branch inbetween) and picking the best time.
To see if this had a real-world effect, I went ahead and did a 'bzr push' of a one-revision branch, in a loop of 20 calls.
1005ms baseline
764ms codehosting-cheaper-failures + makeDeferred
That includes the ssh handshake overhead, and all the other work that 'push' has to do. (Best case 'initialize' calls during this is 408ms for baseline, 159ms patched)
So Andrew put together lp:~spiv/launchpad/codehosting-cheaper-failures, and I did some tracing, and found one more case where we were creating a deferred that always used the default Failure handling. Putting together those patches, I did a bit more perf testing. The following numbers are running 'initialize' multiple times (deleting the branch inbetween) and picking the best time.
703ms baseline (no modifications) gProxy, special 'makeDeferred' cheaper- failures cheaper- failures + makeDeferred Failure. __init_ _ 'tb = None' always
573ms DeferredBlockin
255ms codehosting-
173ms codehosting-
180ms baseline, hacking Twisted.
To see if this had a real-world effect, I went ahead and did a 'bzr push' of a one-revision branch, in a loop of 20 calls. cheaper- failures + makeDeferred
1005ms baseline
764ms codehosting-
That includes the ssh handshake overhead, and all the other work that 'push' has to do. (Best case 'initialize' calls during this is 408ms for baseline, 159ms patched)