copy.deepcopy по сравнению с рассолом
iTextSharp http://itextsharp.sourceforge.net/
, Сложный но всесторонний.
3 ответа
Проблема в том, что pickle + unpickle может быть быстрее (в реализации C), потому что он менее общий , чем deepcopy: многие объекты могут быть глубоко скопированы, но не обработаны. Предположим, например, что ваш класс A был изменен на ...:
class A(object):
class B(object): pass
def __init__(self): self.b = self.B()
теперь, copy1 по-прежнему работает нормально (сложность A замедляет его, но абсолютно не останавливает); copy2 и copy3 break, конец трассировки стека говорит ...:
File "./c.py", line 20, in copy3
return cPickle.loads(cPickle.dumps(d, -1))
PicklingError: Can't pickle <class 'c.B'>: attribute lookup c.B failed
Т.е., обработка всегда предполагает, что классы и функции являются объектами верхнего уровня в своих модулях, и так что солит их «по имени» - глубокое копирование абсолютно не делает таких предположений.
Так что, если у вас есть ситуация, когда скорость «некоторого глубокого копирования» является абсолютно решающей, каждая миллисекунда имеет значение,
Еще быстрее было бы вообще избежать копирования. Вы упомянули, что делаете рендеринг. Зачем нужно копировать объекты?
Вам следует использовать глубокое копирование, потому что это делает ваш код более читабельным. Использование механизма сериализации для копирования объектов в память как минимум сбивает с толку другого разработчика, читающего ваш код. Использование Deepcopy также означает, что вы получите преимущества будущих оптимизаций в Deepcopy.
Первое правило оптимизации: не делайте этого.