Современные цифровые инструменты для совместной работы, такие как Figma, постоянно сталкиваются с растущими вызовами в масштабировании и производительности. Одной из ключевых задач является обеспечение быстрой загрузки файлов и эффективного использования памяти при работе с большими и сложными проектами. Понимание и оптимизация этих аспектов напрямую влияют на качество пользовательского опыта, особенно в условиях многопользовательской работы, где файлы активно обновляются и изменяются в режиме реального времени. Одним из эффективных решений стала оптимизация внутреннего устройства хранения данных с применением языка программирования Rust. Команда разработчиков Figma, анализируя нагрузку на серверы и время загрузки файлов, обнаружила существенные возможности для улучшения за счёт изменения структуры данных, используемой для представления узлов внутри файла.
Фундаменом всей файловой структуры Figma является набор узлов, каждый из которых описывает элементы интерфейса — фигуры, фреймы, комментарии и другие объекты. Каждый узел хранит набор свойств, таких как цвет, размер, позиция и иерархия, где они представлены в виде карты соответствия ключей и значений. В первоначальной реализации использовался стандартный BTreeMap в Rust для сопоставления идентификаторов свойств (ключей типа u16) с адресами значений (указатели типа u64). Такая структура обеспечивала упорядоченную итерацию, необходимую для процесса сериализации и десериализации файлов. Однако, проведённый анализ показал, что именно эта карта потребляет свыше 60% оперативной памяти, выделяемой для работы с отдельным файлом, что представляло серьёзный узкий профиль.
При этом объём ключей был ограничен — в схеме файла насчитывалось менее 200 полей, и не все поля были заполнены одновременно, так как свойства группировались в логические кластеры в зависимости от типа узла. Основываясь на этих наблюдениях, разработчики решили отказаться от традиционной карты в пользу более простой и компактной структуры — отсортированного вектора пар ключ-значение. Такой вектор хранил записи в виде отсортированных кортежей (u16, pointer), что позволяло эффективно хранить около 60 ключей и при этом значительно сэкономить память. Несмотря на то, что с теоретической точки зрения вставка в середину вектора имеет линейную сложность, на практике при десериализации файлов эта структура показала себя быстрее, поскольку компьютеры гораздо эффективнее обрабатывают непрерывные участки памяти. Результаты оптимизации были впечатляющими.
Внедрение векторной структуры позволило снизить использование памяти файла на 25%, а также повысить быстродействие десериализации файлов в среднем на 20% в самых медленных случаях, что является критично важным для ценной части пользовательской базы, работающей с большими либо сложными макетами. Следующим этапом исследований стала попытка ещё более эффективно использовать память, введя концепцию bit stuffing, или упаковки битов. Понимая, что указатель в 64 бита на современных x86 процессорах использует только 48 нижних бит для адресации памяти, оставляя 16 верхних бит свободными, команда предложила объединять идентификатор свойства и указатель в одном 64-битном числе. Такой подход позволял хранить и ключ, и значение одновременно без дополнительных затрат памяти. В реализации использовались операции побитового сдвига и маскирования для извлечения обеих частей данных.
При этом особое внимание уделялось корректному управлению временем жизни указателей с учётом использования счетчиков ссылок, что критично для предотвращения ошибок и утечек памяти. Несмотря на то, что бенчмарки показали незначительный прирост производительности и небольшое снижение используемой памяти (около 5% по сравнению с предыдущим вариантом), команда решила не внедрять это улучшение в продакшен. Основной причиной стала сложность поддержки такого кода и риск возникновения трудноуловимых ошибок, а также то, что реальная экономия ресурсов не была критичной для текущих задач. Тем не менее, этот метод остаётся перспективным рычагом оптимизации для будущих версий. В целом, переход от стандартной map-структуры к отсортированному вектору стал важным шагом для Figma в деле повышения скорости загрузки файлов и уменьшения потребления памяти серверов.
Быстрая обработка данных напрямую влияет на качество пользовательского опыта, сокращая задержки и делая работу с крупными и сложными макетами более комфортной. Такая оптимизация — лишь одна из многих, которые Figma внедряет для поддержки масштабируемости и надёжности своей мультиплеерной системы. Оптимизации с акцентом на эффективное использование памяти и вычислительных ресурсов не ограничиваются только структурой хранения. В рамках общих усилий команда также внедряет динамическую загрузку страниц, инкрементальную загрузку компонентов и другие техники, способствующие снижению нагрузки и ускорению отклика приложения. Все эти меры в совокупности позволяют обслуживать возрастающий поток пользователей и огромные объёмы данных без потери качества и стабильности работы.
Для разработчиков и инженеров, заинтересованных в производительности и масштабируемости современных веб-приложений, опыт Figma с применением Rust и продуманной оптимизацией структур данных служит отличным примером. Это демонстрирует, как глубокий анализ и отказ от универсальных, но тяжеловесных решений в пользу специализированных подходов могут привести к значительному улучшению ключевых показателей скорости и эффективности. Таким образом, Figma продолжает инвестировать в свои технологии, двигаясь вперёд благодаря инновациям и тщательной инженерной работе. Перспективы дальнейших оптимизаций в памяти и производительности открывают интересные возможности для повышения качества инструментов совместного проектирования и разработки, отвечая потребностям современной цифровой индустрии.
