Moscow Python Meetup №91. Махмуд Кудусов (Иви.ру, backend разработчик). Подход к переиспользованию go-шной библиотеки в Python малой кровью

В этом докладе будет рассказ о том, как ленивые разработчики не захотели писать и поддерживать один и тот же фукнционал на языках Golang и Python, и решили вызывать гошный код из питона. Какой подход обмена структурами можно использовать, если методы принимают и возвращают "сложные структуры"? Сильно ли отличается скорость выполнения нативной реализации на питоне от примененного подхода?

Видео: https://moscowpython.ru/meetup/91/go-in-python/

Moscow Python: http://moscowpython.ru
Курсы Learn Python: http://learn.python.ru
Moscow Python Podcast: http://podcast.python.ru
Заявки на доклады: https://bit.ly/mp-speaker

Transcript

1. © 2024, ВСЕ ПРАВА ЗАЩИЩЕНЫ Подход к переиспользованию GO-библиотеки в Python Махмуд Кудусов backend-разработчик, операционная команда b2b
2. Давайте знакомиться Махмуд Кудусов Backend-разработчик 4 года в Иви © 2024, ВСЕ ПРАВА ЗАЩИЩЕНЫ
3. №1 среди работодателей 830+ Экспертов и профессионалов 14 Лет на рынке Иви сегодня Производство собственного контента Сильный бренд Собственная технологическая платформа Лояльная вовлечённая аудитория
4. Повестка доклада 1. 2. Зачем нам понадобилось вызывать GO библиотеку из Python? Рассмотрим на примерах, как это можно организовать Попытаюсь убедить вас, насколько неудобным становится код, когда функции начинают принимать и возвращать чуть более сложные структуры данных 4. 5. 6. Поговорим про варианты, как можно облегчить себе жизнь в таких случаях Проведем сравнительный анализ скорости выполнения и объема потребляемой памяти Подведем итоги 3.
5. Зачем нам это? Дано Реализовать 2 библиотеки на Python и GO с абсолютно идентичным предоставляемым функционалом Планируется внедрить библиотеку во множество микросервисов Библиотека хранит в памяти большой объем данных Чем компактнее будем хранить данные (особенно актуально для Python) – тем лучше Чем раньше реализуем – тем лучше
6. Зачем нам это? Идея А почему бы не сделать реализацию на одном языке, и вызывать это из другого? Какие есть варианты: Решили основную логику реализовать на Go. Почему? Go быстрее Типы данных в Golang занимают меньше памяти Реализовать на Python и переиспользовать в Go Реализовать на GO и переиспользовать в Python
7. CGO – пакет в Go, позволяющий вызывать C из GO, и наоборот экспортировать методы, которые могут вызываться из C Python очень неплохо справляется с вызовом динамических библиотек С Как это работает?
8. Небольшой пример Билдим динамическую библиотеку
9. Содержимое _main.h Вызов из Python Небольшой пример
10. Запускаем пример и радуемся, что все работает На первый взгляд никаких сложностей – все круто Далее попробуем реализовать функцию, которая возвращает чуть более сложную структуру Небольшой пример
12. Возврат более сложной структуры Такого же магического комментария export для GO- структур cgo не предоставляет Нужно описать необходимую нам структуру в виде C-структуры Описываем нужную нам структуру прямо в .go файле CGO сам распарсит, и раскинет в .h файл
13. Дожили и до ручного управления памяти в Golang :( Не стоит забывать, что все что мы тут выделили, надо будет почистить Возврат более сложной структуры
14. В Python выглядит все сильно цивильнее Важно, чтобы порядок полей в _fields_ соответствовал порядку полей структуры С Возврат более сложной структуры
15. Подчищаем за собой не забыл почистить за собой?
16. Мы привыкли писать на Python и GO, где сборщик мусора подчищает за тобой При разрастании и/или усложнении структуры, увеличивается вероятность что-то не дочистить Сложные приведения типов/структур GO -> C -> Python и Python -> C -> GO (а это была только верхушка айсберга) Разработчикам, не знакомым с языком C, сложно это поддерживать Минусы такого подхода 1. 2. 3. 4.
17. Более удобный механизм возвращать структуры из GO Минимизировать логику конвертации типов и структур Python -> C -> GO и GO -> C -> Python Минимизировать ручное выделение/освобождение памяти Чего хотим? Как можно этого добиться? Передавать в функции и возвращать из них сериализованные json Передавать в функции и возвращать из них сериализованные protobuf-сообщения
18. Схема с proto-сообщениями
19. Опишем аналогичные protobuf-структуры: Схема с proto-сообщениями
20. Схема с proto-сообщениями
21. Плюсы и минусы такого подхода Не надо описывать все в C структурах Не надо реализовывать сложную логику по конвертации типов и структур Не надо выделять память вручную Проще процесс зачистки памяти за собой Плюсы Накладные расходы на сериализацию /десериализацию объектов Минусы
22. Сравнение времени вызова функций Подход с обменом protobuf ~23% хуже по скорости
23. Для проверки производительности реализовал на Python и GO идентичную логику А что по производительности? Сигнатура реализованной функции такая: Для одного элемента выполняются следующие действия: 1. 2. 3. две операции проверки вхождения во множество три операции get из словаря три операции нахождения полного пересечения множеств
24. Сравнение Python, Python + GO, GO
25. Сравнение потребляемой памяти Храним 50000 объектов следующего типа Python-приложение потребляет 3.6 GB GO потребляет 1.1 GB Разница ~3.5 раза
26. Оправдались ли наши ожидания? Итоги Не писать одну и ту же логику дважды Python-библиотека требует меньше памяти, чем могла бы В каких-то моментах Python библиотека даже ускорилась Новые доработки требуют в два раза меньше времени
27. Выоды Вызов GO библиотек из Python вполне жизнеспособный вариант Можно сильно упростить разработку / поддержку /жизнь используя унифицированные описания (в нашем случае протобаф) Стали бы мы такое делать, если бы не было необходимости в реализации GO библиотеки? Скорее всего, нет
28. Вопросы?
29. Увидимся! Твой