Information
- Rating
- Does not participate
- Location
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Date of birth
- Registered
- Activity
Specialization
Backend Developer, Web Developer
Middle
Python
Django
PostgreSQL
Redis
Celery
Rust
English
REST
Fastapi
SQLalchemy
Привет, возможность скинуть данные нет, но есть подозрение что я допустил ошибку когда сравнивал перформанс, в детали пока вдаваться не буду, сейчас большая загрузка на проектах, постараюсь вернуться с развернутым ответом в ближайшую неделю/на следующей неделе, как только протестирую все еще раз.
Я не Rust разработчик и про лучшие практики знаю мало, но судя по этому правилу такое написание рекомендуется для Ref counter-ов https://rust-lang.github.io/rust-clippy/master/index.html#/clone_on_ref_ptr
На момент реализации, часть библиотек не работала с 3.12, не знаю как ситуация обстоит сейчас, поэтому этот вариант не рассматривался
Привет, по сути основная просадка заключается в том, как собирается древовидная структура (маппинг по id сначала дерева съютов и затем маппинг кейсов к этим съютам), нам нужно отдать все данные разом, и более того этот endpoint отвечает за поиск и должен быть сильно отзывчивым, чтобы фронт мог подгрузить дерево выбора, и условие в том что фронт мы менять не можем, DRF сериализатор при сборе всех данных которые нам нужны использует related managers, и это получается сильно дорого, так как это все получение ORM объектов и их cpu-bound сериализация, если мы исключим Rust из уравнения и сделаем в python тоже самое, что мы отдали на выполнение Rust-у c использованием values, то получим результат быстрее, чем DRF, но он все равно будет хуже чем у раста потому что все равно остается cpu-bound задача на циклах, в самом большом проекте, который у нас есть, решение на values и простых циклах в python мы получаем +-8 секунд, с Rust результат меньше секунды.