Changes between and of Initial VersionVersion 21Ticket #5011


Ignore:
Timestamp:
04/03/2011 02:32:39 PM (8 years ago)
Author:
Jean-Paul Calderone
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #5011

    • Property Cc Tristan Seligmann added
    • Property Priority changed from normal to high
    • Property Branch changed from to branches/faster-failures-5011
    • Property Author changed from to spiv
  • Ticket #5011 – Description

    initial v21  
    33At Canonical we recently noticed Launchpad's codehosting spending a surprising amount of time in `twisted.python.failure.Failure.__getstate__`, as reported in http://twistedmatrix.com/pipermail/twisted-python/2011-March/023755.html.  The result is that an operation that should take a small handful of milliseconds is taking 2-5× longer, because Twisted is spending that time cleaning failures that are about to be discarded entirely.
    44
    5 The problem is essentially that capturing the full traceback is expensive (and the deeper your call stack, and the more variables you have, the worse it is, and Deferred doesn't have a good idea of when that information will be useful, so much of the time capturing and processing it wasted.
     5The problem is essentially that capturing the full traceback is expensive (and the deeper your call stack, and the more variables you have, the worse it is), and Deferred doesn't have a good idea of when that information will be useful, so much of the time capturing and processing it wasted.
    66
    77The current policy is that if a call/errback raises an error, it constructs a failure by calling `Failure()`, which will capture the traceback in the Failure (unless the error is already a Failure instance, in which case the new Failure shares a `__dict__` with the raised one).  At this point it's mainly just keeping a reference to a traceback object, so not particularly expensive by itself.