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