Часто в литературе, сети Интернет и в коде реальных проектов можно встретить такое использование генераторных выражений:

total = sum([x for x in sequence])

Такой код хоть и правильный с точки зрения синтаксиса, тем не менее не является оптимальным. В большинстве случаев правильнее писать так:

total = sum(x for x in sequence)

Разница в том, что в первом случае в функцию sum передается список, созданный на основе генератора, а во втором — генератор. Для создания списка нужно выполнить дополнительные операции, а также выделить дополнительную память. При этом результат работы всего кода будет тот же самый.

Вывод: создавайте коллекции (кортежи, списки и т.п.) на основе генераторов только там, где это действительно нужно.

#python #оптимизация

Периодически на ревью вижу примерно такое использование функций all и any:

if any((
    is_check1_passed(),
    is_check2_passed(),
    ...
)):
    pass

Скорее всего это делается для повышения читаемости кода, но это только моё предположение. С точки зрения логики программы это почти всегда рабочий код. Но вот с точки зрения оптимальности есть проблемы.

Дело в том, что этом случае будут выполнены все проверки вне зависимости от результатов каждой из них. Также будет создан дополнительный кортеж, который потребует, хоть и несущественного, но всё же выделения памяти и процессорного времени.

Более оптимальный код выглядит так:

if (
    is_check1_passed() or
    is_check2_passed() or
    ...
):
    pass

При использовании логических операторов будет вычисляться только необходимый минимум операндов. В примере выше если проверка 1 пройдет, то остальные проверки выполняться не будут.

Использование функций all и any актуально в первую очередь при использовании генераторов, т.к. за счет отложенности вычисляться будет только необходимый минимум операндов.

Описание функций all и any: https://docs.python.org/3.6/library/functions.html#all

#python #оптимизация

В Python есть такие структуры данных, как кортежи (tuple) и списки (list). В книгах, статьях, в реальных проектах чаще встречается использование списков вместо кортежей там, где в этом нет необходимости:

gender = models.PositiveIntegerField(
    'Пол',
    choices=[GENDER_MALE, GENDER_FEMALE],
)

При хранении одних и тех же данных списки занимают больше места, чем кортежи. Например, на 64-хразрядной системе для хранения двух элементов в списке нужно 80 байт, а в кортеже — 64 (на 16 байт меньше). Для 1000 элементов отличие будет уже на 1064 байта. Это несущественно на небольших проектах, но становится актуальным для больших информационных систем, работающих с большим количеством данных, особенно в совокупности с другими способами оптимизации.

Совет: там, где нет потребности в изменении содержимого коллекции, используйте кортежи вместо списков.

#python #оптимизация

В отличие от кортежей и списков, множества (set, frozenset) и словари (dict) занимают больше места в памяти. Например, для множества из двух элементов понадобится 224 байта (кортеж — 64). Для 1000 элементов — 32992 и 8048 соответственно.

Однако у словарей и множеств есть важное преимущество: скорость поиска элемента в коллекции (оператор in). Если для кортежей и списков сложность данной операции равна O(n), то для множеств это O(1). Сравните:

In [2]: a = {randint(1, 10000000) for _ in range(1000000)}

In [3]: len(a)
Out[3]: 951498

In [4]: %timeit randint(1, 10000000) in a
1.86 µs ± 19.1 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

Для множества из почти миллиона целых чисел время поиска случайного числа составляет в среднем 1.86 µs. Теперь сделаем замеры для множества из ста целых чисел, т.е. в 10 000 раз меньше:

In [5]: a = {randint(1, 10000000) for _ in range(100)}

In [6]: len(a)
Out[6]: 100

In [7]: %timeit randint(1, 10000000) in a
1.75 µs ± 13.2 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

Из этих замеров видно, что время поиска элемента практически не зависит от количества элементов в коллекции, т.е. равно O(1). Поиск ключа в словаре работает с аналогичной скоростью.

Совет: для решения задач, в которых интенсивно используется поиск элемента в коллекции, используйте словари и множества.

#python #оптимизация

В двух предыдущих сообщениях я приводил размеры коллекций в байтах, при этом не делал оговорок по поводу того, какой тип данных хранится в коллекции. Это не ошибка. В коллекциях хранятся только ссылки на объекты (указатели, адреса), а размер указателя определяется разрядностью интерпретатора: в 32-хразрадном — 4 байта, в 64-хразрадном — 8 байт. Поэтому размер коллекции по сути не зависит от типа данных, содержащихся в ней.

#python

Как известно, в Python поддерживается множественное наследование. С учетом этого классы можно разделить на три вида: обычные классы, абстрактные базовые классы и классы-примеси.

Обычные классы предоставляют доступ к своему функционалу через свои экземпляры.

Абстрактные базовые классы, наоборот, не предполагают создания экземпляров, т.к. требуют реализации абстрактных методов в потомках. В ООП есть еще интерфейсы, но в языках с поддержкой множественного наследования они не выделяются в отдельную конструкцию, а реализуются через абстрактные базовые классы, состоящие только из абстрактных методов.

Классы-примеси (mixins) содержат только часть реализации, "подмешиваемой" к другим классам.

Рассмотрим вышесказанное в контексте MRO (Method Resolution Order). При использовании в классах-потомках доступ к методам базовых классов осуществляется через super. Если иерархия наследования включает несколько уровней, то цепочка вызовов super пройдет как раз в соответствии с MRO. Если коротко, то последовательность вызовов в иерархии будет идти слева направо, снизу вверх. Также стоит отметить, что если в методе не вызывается super, то цепочка вызовов завершается на таком методе.

Исходя из этого список базовых классов нужно формировать в следующем порядке:

1. Классы-примеси.
Т.к. их смысл в первую очередь в том, чтобы расширять другие классы, они по определению должны содержать вызов super. Это означает, что цепочка вызовов не прервется в классе-примеси и функционал основного класса будет достижим. Если же указать класс-примесь после обычного класса, то при наличии абстрактных классов в иерархии наследования может быть вызван абстрактный метод, что в Python приводит к ошибке.

2. Обычные классы.
В конце иерархии наследования обычных классов всегда есть метод, на котором заканчивается цепочка вызовов. Прежде всего это важно при переопределении абстрактных методов. Именно поэтому наличие перед абстрактными базовыми классами в списке наследования обычного класса гарантирует отсутствие ошибок при вызове методов.

3. Абстрактные базовые классы.
Как было сказано выше, вызов абстрактного метода возможен через super и это приводит к ошибке. Поэтому абстрактные классы в списке классов-предков нужно указывать последними, тогда цепочка вызовов завершится на обычном классе. Но при этом останется доступен функционал абстрактных классов в части контрля обязательности переопределения всех абстрактных методов и свойств (в т.ч. контроль реализации интерфейсов).

Совет: в списке наследования сначала указывайте классы-примеси, затем обычные классы и только потом абстрактные базовые классы.

#python #ООП

Ссылки:
- описание модуля abc https://docs.python.org/3/library/abc.html

В таких языках, как C++, Java, C#, PHP и др. реализованы т.н. модификаторы доступа: public, protected и private. С их помощью можно указать степень сокрытия членов класса. Если коротко, то означают они следующее: public — члены класса доступны отовсюду, protected — из методов самого класса и его потомков, private — только из методов класса.

В Python таких модификаторов доступа нет и все члены класса доступны отовсюду. При этом есть соглашение (https://docs.python.org/3/tutorial/classes.html#private-variables) по именованию членов класса, согласно которому они разделяются на три типа, у которых имя:

1. НЕ начинается с символа подчеркивания (foo);
2. начинается с одного символа подчеркивания (_bar);
2. начинается с двух символов подчеркивания (__baz).

Отдельную группу составляют члены классов со специальными именами, начинающимися и заканчивающимися с двойного подчеркивания, но сейчас речь не о них.

Аналогия между модификаторами доступа и именами в Python следующая:

1. public — нет подчеркивания, можно использовать отовсюду;
2. protected — один символ подчеркивания, можно использовать только в методах класса и его потомках;
3. private — два символа подчеркивания, можно использовать только в методах класса.

Совет 1: при проектировании классов уделяйте должное внимание сокрытию его членов, служебные атрибуты и методы, не предназначенные для использования извне, делайте закрытыми.

Совет 2: Не нарушайте соглашения по именованию членов класса, т.к. в будущих версиях этого класса его внутреннее устройство может измениться, что нарушит работоспособность вашей программы.

#python #ООП

Все имена в Python являются ссылками на объекты. Имена переменных, классов, функций и т.д. — это только адрес объекта в памяти, но не сам объект. Убедиться в этом можно с помощью функции id, которая возвращает уникальный идентификатор объекта (в CPython -- адрес объекта в памяти):

>>> import datetime
>>> id(datetime)
139662440951544
>>> a = datetime
>>> id(a)
139662440951544

Ссылаться на объект можно не только из переменных, но и из элементов коллекций (tuple, 'list и т.д.), атрибутов классов. При этом у каждого объекта есть счетчик ссылок. При создании ссылки на объект счетчик ссылок увеличивается, а при удалении ссылки — уменьшается. Когда счетчик ссылок равен 0, объект удаляется из памяти.

Однако в Python есть возможность ссылаться на объекты не увеличивая счетчик ссылок. Делается это с помощью слабых ссылок (weak references). Инструментарий для работы со слабыми ссылками расположен в модуле стандартной библиотеки weakref:
- класс ref для создания слабой ссылки на объект;
- словарь WeakKeyDictionary с ключами, являющимися слабыми ссылками;
- словарь WeakValueDictionary со значениями, являющимися слабыми ссылками;
- множество WeakSet
и другое.

В коллекциях WeakKeyDictionary, WeakValueDictionary и WeakSet элементы существуют до тех пор, пока сущестует объект, на который ссылается слабая ссылка:

>>> d = WeakKeyDictionary()
>>> class C:
        pass
>>> c = C()
>>> d[c] = 'qwerty'
>>> len(d)
1
>>> del c
>>> len(d)
0

Например, недавно я использовал WeakKeyDictionary для оптимизации работы функции get_original_object, которая по объекту модели Django возвращает его исходное состояние, заново загружая его из БД. Это нужно для того, чтобы сравнить, какие поля в объекте изменились и выполнить соответствующие действия. Особенность использования функции была в том, что она могла вызываться для одного и того же экземпляра модели много раз в разных частях системы. Для того, чтобы предотвратить повторную загрузку объектов в этой функции, был задействован словарь WeakKeyDictionary для организации кэша исходных объектов:

_get_original_object_cache = WeakKeyDictionary()

def get_original_object(obj):
    if obj in _get_original_object_cache:
        return _get_original_object_cache[obj]
    ...

За счет того, что записи в таком словаре существуют только пока существует объект, на который ссылается ключ, удаление кешированных объектов происходит вместе с основным объектом и нет необходимости заботиться об очистке кэша.

Совет: ознакомьтесь с содержимым модуля weakref и возможностями слабых ссылок, они могут быть полезны для решения некоторых задач, в т.ч. кеширования.

#python

Ссылки:
- модуль weakref: https://docs.python.org/3.6/library/weakref.html

Метод iterator() в Django ORM

В Django ORM загрузка объектов модели из БД осуществляется через один из её менеджеров. У менеджера, а также у QuerySet, есть метод iterator(). О нем и пойдет речь.

При выполнении SELECT-запроса QuerySet по умолчанию загружает ВСЕ записи (строки) и для КАЖДОЙ из них создает экземпляр модели (кеширует). В большинстве случаев результаты выполнения запроса обрабатываются в цикле и каждый из созданных объектов используется только на одной итерации цикла. Очевидно, что при этом необходимости хранить в памяти экземпляры модели для всех записей нет. Это особенно актуально, когда запрос возвращает много записей, каждая из которых занимает память.

Метод iterator() позволяет отключить такое кэширование и оптимизировать использование памяти при обработке данных. А в Django 1.11+ для Oracle и PostgreSQL также используются серверные курсоры, что позволяет еще лучше оптимизировать использование памяти приложением, т.к. данные с сервера БД будут загружаться порциями по 100 записей (см. GET_ITERATOR_CHUNK_SIZE).

for obj in TestModel.objects.filter(...).iterator():
    ...

Для values() и values_list() также можно отключать кеширование.

Примечание 1: при использовании iterator() игнорируется prefetch_related().
Примечание 2: при использовании пулов соединений с БД серверные курсоры нужно отключать (см. параметр DISABLE_SERVER_SIDE_CURSORS).

Совет: при обходе QuerySet-ов в циклах, где не нужно повторное использование экземпляров моделей, отключайте их кэширование с помощью метода iterator().

#django #оптимизация

Django ORM: on_commit

Иногда появляется необходимость выполнить какие-то действия сразу после коммита. Одним из примеров такой ситуации является удаление записей с полями на основе FileField (в т.ч. ImageField). Эти поля предназначены для хранения файлов, но в БД хранится только путь к файлу, а сам файл хранится в файловой системе или другом хранилище. При удалении такой записи Django ORM НЕ удаляет файл. Поэтому при интенсивном добавлении/удалении записей в такой модели будет как минимум нерационально использоваться дисковое пространство.

В документации Django сказано, что разработчикам нужно самостоятельно позаботиться об удалении файлов. Также там предлагается использовать для этих целей management-команды и их периодический запуск (например, через cron). Начиная с Django 1.9 и выше доступен более оптимальный способ для удаления файлов, на которые уже нет ссылок в БД. Речь о функции on_commit в модуле django.db.transaction. Её первый аргумент — callable-объект, которая будет вызвана сразу после успешного коммита текущей транзакции.

@receiver(post_delete)
def delete_files(sender, instance, using, **kwargs):
    for field in sender._meta.get_fields():
        if isinstance(field, FileField):
            file = getattr(instance, field.name)
            if file:
                on_commit(file.delete, using)

Почему неправильно удалять файл сразу в обработчике post_delete? Дело в том, что обработчики сигналов вызываются внутри транзакции, а значит по тем или иным причинам может произойти откат транзакции, т.е. данные в БД будут возвращены к исходному состоянию. В итоге ссылка на файл останется в БД, а вот самого файла уже не будет.

Еще один пример — это отправка пользователям уведомлений о выполнении каких-либо операций. Отправлять письмо о том, что в системе была выполнена какая-либо операция, нужно только после того, как будут сохранены в БД соответствующие изменения, т.е. после коммита. Иначе после отправки письма дальнейшие операции могут привести к ошибке и откату транзакции в БД, но письмо уже не отменишь.

Совет: при взаимодействии с внешними относительно СУБД системами (файловые системы, почтовые серверы и т.п.) помните о возможности отката транзакции и откладывайте все действия до её подтверждения с помощью on_commit.

#django

Ссылки:
- функция on_commit: https://docs.djangoproject.com/en/2.0/topics/db/transactions/#django.db.transaction.on_commit