Конечно, на этот вопрос можно дать несколько разных ответов, но нас интересует одно из самых крупных изменений в Polars — изменение структуры данных для строк.
Почему вспоминаем про это сейчас?
Потому что это все еще интересно — статья рассказывает про тонкости работы Polars, про которые кто-то может и не задумывался.
В чем суть?
Изначально Polars следовали спецификации Apache Arrow, но решили отойти от этого формата, чтобы улучшить производительность.
В Apache Arrow данные строкового типа «проходят» через три буфера: буфер валидности, общий буфер
data и дополнительный буфер с оффсетами для определения начала и окончания каждой строки. Такой формат обеспечивал компактность, но у него были и недостатки:🔵Сложно заранее определить, сколько памяти надо выделить под строки,
🔵Операции
gather и filter начинали тормозить при работе с длинными строками. Это и подтолкнуло к переходу на формат, который используется в Hyper/Umbra. Здесь строки хранятся в «представлениях» — колонках фиксированной ширины по 16 байт. Короткие строки до 12 байт встраиваются напрямую, длинные — в отдельный буфер. В оригинале статьи есть наглядные схемы, как это работает.
Новый подход обеспечивал быстрый доступ к коротким строкам, поддержку интернирования для длинных, стабильное время выполнения операций
filter и gather и вообще в целом оказался удобнее. Минусы у него тоже были — например, пришлось пожертвовать компактностью в пользу скорости обработки данных.🔜 Но все было не зря — судя по бенчмаркам в конце статьи, переход на новый формат дал значительный прирост производительности, особенно при работе с «тяжелыми» строками.