dict имеет наибольшую скорость доступа по ключу. До python3.11 класс со __slots__ имеет меньшую скорость доступа. С python3.11 появилась оптимизация доступа для экземпляров со __slots__, которая делает скорость доступа очень высокой. recordclass.recordclass/dataobject имеет более высокую скорость создания экземпляра, и высокую скорость доступа. В стандартном варианте скорость создания экземпляра со __slots__ невысокая. Для сравнения можно посмотреть таблицу сравнения производительности в README (https://github.com/intellimath/recordclass/blob/main/README.md)
Note, objects like ``namedtuples``, ``closure``, and NumPy data
``arange``, ``array``, ``matrix``, etc. are only handled by recent
versions of this module. Sizing of ``__slots__`` has been incorrect
in versions before this one. Also, property ``Asizer.duplicate`` gave
incorrect values before this release. Several other properties
have been added to the ``Asizer`` class and the ``print_summary``
method has been updated.
Поэтому для того, чтобы pympler мог давать верный размер для объектов, порожденных подклассами dataobject, его нужно сначала "научить" )
Обвинения в конспирологии стали столь часты, что наводят на мысль, что эти самые обвинения суть банальный ментальный прием для того, чтобы заблокировать поиск истины в "запретных" областях.
Для экземпляров классов, порожденных recordclass и унаследованных от dataobject pympler не может вычислить правильный размер экземпляра. Похоже, что для экземпляров классов со __slots__ тоже почему-то дает завышенное значение.
Вы правы, это вышло за скобки. Я не преследовал цель сделать полный обзор. Но отметил наиболее часто используемые. Что касается array.array для большого числа значений, выигрыш по памяти есть, так же как и в случае с numpy. Но остается нагрузка в связи с необходимостью преобразования С-шных типов в Python-овские и наоборот. Если выигрыш в памяти важнее, чем потеря производительности в связи с boxing/unboxing, то да действительно это работает. Что касается ctypes.Structure, у меня нет опыта работы с ctypes. Однако, исторически ctypes создавался для того, чтобы обеспечивать доступ к структурам, которые изначально живут в бинарных модулях (dll/so), которые создавались при помощи C/C++ или следовали соответствующим конвенциям.
Проблема boxing/unboxing здесь остается.
В статье основной акцент старался сделать на том, как в "чистом" Python добиться уменьшения потребления памяти при создании объектов, которые тоже состоят из Python-овских объектов.
В Python есть основной механизм подсчета ссылок на объект. Если объект таков, что циклические ссылки на него в графе зависимостей между объектами не возникают, то после того, как счетчик ссылок (находится в заголовке объекта PyObject_HEAD) обнуляется, что означает что объект более никем не используется, то автоматически утилизируется из памяти. Тут правда есть нюансы, связанные с распределителем памяти объектов в Python, но оставим это за скобками. Дополнительно есть механизм для утилизации для объектов, в которым возможны циклические ссылки. В объекте-типе для классов установлен специальный флаг, который сигнализирует, что объект должен быть утилизирован через механизм циклической сборки мусора, который включает в себя обход таких объектов с целью ликвидации циклов в графе зависимостей между объектами. Для простых объектов типа str, long, date/time такой флаг не выставлен и они утилизируются через механизм подсчета ссылок. Контейнерные типы list, dict, любой класс созданный через обычное определение class, и даже немутируемый tuple имеют такой флаг. Однако не всегда маркирование класса автоматически, как потенциальный для возникновения циклических ссылок, оправдано. Например, объекты, которые представляют простые структуры, которые в графе зависимостей между объектами по-существу являются терминальными. Корректное использование таких классов не приводит к возникновению циклических ссылок. Поэтому здесь механизм циклической сборки мусора избыточен и может быть и может быть исключен.
Задавшему вопрос отдельная благодарность за возможность прояснить ситуацию.
Здесь срабатывает механизм подсчета ссылок. Как только количество ссылок станет равным нулю, объект сразу утилизируется. Предполагается, что циклические ссылки на этот объект не возникают.
AXON создавался как нотация для текстового представления объектов/данных, который бы, по возможности, объединил достоинства JSON, XML и YAML, а также по возможности избежал их недостатков. Если не всех, то основных.
Поэтому говорить, что YAML хуже чем AXON или наоборот некорректно.
AXON это текстовая нотация для представления данных (текст в формате unicode). Сообщение AXON представляет последовательность значений или последовательность пар ключ:значение. Поэтому читать из потока и писать в поток каждое значение или пару ключ: значение можно итеративно в отличие от JSON.
Есть несколько тестов сравнения скорости загрузки/дампа с JSON. Дамп отстает от JSON в среднем на 10-15%, загрузка в среднем на 20-50% (по моим наблюдениям эти цифры можно немного уменьшить). Естественно, что скорость загрузки/дампа в случае JSON будет быстрее, так он имеет более простую структуру. Однако при загрузке/дампе очень больших последовательностей данных AXON выигрывает из-за того, что не нужно сначала строить всю последовательность в памяти. Сравнение производительности проводилось для реализации pyaxon и модуля json из стандартной библиотеки версии 3.5. Для более ранних версий python (2.7 — 3.4) процентные величины меньше (в python 3.5. производительность json заметно улучшена).
Сравнение с MessagePack не производилось, так как из общих соображений ясно, что производительность для сообщений, содержащих числовые данные будут кодироваться и декодироваться существенно быстрее в MessagePack, посколько AXON является текстовым форматом. Так что сравнивать имеет смысл только сообщения, содержащие структурированный текст.
По поводу профита. AXON главным образом создавался для текстовой сериализации. Писать конфиги можно, но это не имелось ввиду, так как считаю что YAML вполне подходит для этого.
dict имеет наибольшую скорость доступа по ключу. До python3.11 класс со
__slots__имеет меньшую скорость доступа. С python3.11 появилась оптимизация доступа для экземпляров со__slots__, которая делает скорость доступа очень высокой. recordclass.recordclass/dataobject имеет более высокую скорость создания экземпляра, и высокую скорость доступа. В стандартном варианте скорость создания экземпляра со__slots__невысокая. Для сравнения можно посмотреть таблицу сравнения производительности в README (https://github.com/intellimath/recordclass/blob/main/README.md)Вот jupyter notebook с некоторыми замерами по памяти и времени выполнения на (искусственных) примерах создания деревьев.
Да, останется.
Для того чтобы понять почему (см. https://raw.githubusercontent.com/pympler/pympler/master/pympler/asizeof.py):
Поэтому для того, чтобы pympler мог давать верный размер для объектов, порожденных подклассами
dataobject, его нужно сначала "научить" )Обвинения в конспирологии стали столь часты, что наводят на мысль, что эти самые обвинения суть банальный ментальный прием для того, чтобы заблокировать поиск истины в "запретных" областях.
Thanks! Fixed.
Для экземпляров классов, порожденных recordclass и унаследованных от dataobject pympler не может вычислить правильный размер экземпляра. Похоже, что для экземпляров классов со
__slots__тоже почему-то дает завышенное значение.Можно создавать классы с поддержкой weakref, но без участия в механизме циклической сборки мусора:
или
Вы правы, это вышло за скобки. Я не преследовал цель сделать полный обзор. Но отметил наиболее часто используемые. Что касается
array.arrayдля большого числа значений, выигрыш по памяти есть, так же как и в случае сnumpy. Но остается нагрузка в связи с необходимостью преобразования С-шных типов в Python-овские и наоборот. Если выигрыш в памяти важнее, чем потеря производительности в связи с boxing/unboxing, то да действительно это работает. Что касаетсяctypes.Structure, у меня нет опыта работы с ctypes. Однако, исторически ctypes создавался для того, чтобы обеспечивать доступ к структурам, которые изначально живут в бинарных модулях (dll/so), которые создавались при помощи C/C++ или следовали соответствующим конвенциям.Проблема boxing/unboxing здесь остается.
В статье основной акцент старался сделать на том, как в "чистом" Python добиться уменьшения потребления памяти при создании объектов, которые тоже состоят из Python-овских объектов.
В Python есть основной механизм подсчета ссылок на объект. Если объект таков, что циклические ссылки на него в графе зависимостей между объектами не возникают, то после того, как счетчик ссылок (находится в заголовке объекта
PyObject_HEAD) обнуляется, что означает что объект более никем не используется, то автоматически утилизируется из памяти. Тут правда есть нюансы, связанные с распределителем памяти объектов в Python, но оставим это за скобками. Дополнительно есть механизм для утилизации для объектов, в которым возможны циклические ссылки. В объекте-типе для классов установлен специальный флаг, который сигнализирует, что объект должен быть утилизирован через механизм циклической сборки мусора, который включает в себя обход таких объектов с целью ликвидации циклов в графе зависимостей между объектами. Для простых объектов типа str, long, date/time такой флаг не выставлен и они утилизируются через механизм подсчета ссылок. Контейнерные типы list, dict, любой класс созданный через обычное определение class, и даже немутируемый tuple имеют такой флаг. Однако не всегда маркирование класса автоматически, как потенциальный для возникновения циклических ссылок, оправдано. Например, объекты, которые представляют простые структуры, которые в графе зависимостей между объектами по-существу являются терминальными. Корректное использование таких классов не приводит к возникновению циклических ссылок. Поэтому здесь механизм циклической сборки мусора избыточен и может быть и может быть исключен.Задавшему вопрос отдельная благодарность за возможность прояснить ситуацию.
Можно обосновать минус? Что в ответе не верно?
Здесь срабатывает механизм подсчета ссылок. Как только количество ссылок станет равным нулю, объект сразу утилизируется. Предполагается, что циклические ссылки на этот объект не возникают.
Дело именно в том и состоит, что это дело реализации конкретного парсера JSON, а не принципиальное решение на уровне определения нотации.
Я не ответил на вопрос: чем AXON лучше, чем YAML.
AXON создавался как нотация для текстового представления объектов/данных, который бы, по возможности, объединил достоинства JSON, XML и YAML, а также по возможности избежал их недостатков. Если не всех, то основных.
Поэтому говорить, что YAML хуже чем AXON или наоборот некорректно.
AXON это текстовая нотация для представления данных (текст в формате unicode). Сообщение AXON представляет последовательность значений или последовательность пар
ключ:значение. Поэтому читать из потока и писать в поток каждое значение или пару ключ: значение можно итеративно в отличие от JSON.Есть несколько тестов сравнения скорости загрузки/дампа с JSON. Дамп отстает от JSON в среднем на 10-15%, загрузка в среднем на 20-50% (по моим наблюдениям эти цифры можно немного уменьшить). Естественно, что скорость загрузки/дампа в случае JSON будет быстрее, так он имеет более простую структуру. Однако при загрузке/дампе очень больших последовательностей данных AXON выигрывает из-за того, что не нужно сначала строить всю последовательность в памяти. Сравнение производительности проводилось для реализации pyaxon и модуля
jsonиз стандартной библиотеки версии 3.5. Для более ранних версий python (2.7 — 3.4) процентные величины меньше (в python 3.5. производительность json заметно улучшена).Сравнение с MessagePack не производилось, так как из общих соображений ясно, что производительность для сообщений, содержащих числовые данные будут кодироваться и декодироваться существенно быстрее в MessagePack, посколько AXON является текстовым форматом. Так что сравнивать имеет смысл только сообщения, содержащие структурированный текст.
Если нужен просто улучшенный JSON, то на данном этапе есть варианты для выбора:
Не могли бы пояснить вашу мысль на примере?
По поводу профита. AXON главным образом создавался для текстовой сериализации. Писать конфиги можно, но это не имелось ввиду, так как считаю что YAML вполне подходит для этого.
AXON не имеет отношения к HOCON.
Для трансфера в AXON не нужно использовать форматирование с табами и отступами. Тогда получится компактная форма.
Статья увы неполная.
В AXON как в XML можно использовать элементы с именами/тегами.
В библиотеке
pyaxonиспользуется механизм регистрации порождающей функции по имени элемента.Для примера см. комментарий