Когда структуры в Swift — не твои бро
Один из лучших докладов на Mobius 2025 Autumn. Очень люблю, когда докладчик копает глубоко, объясняет хорошо и разочаровывает меня в Swift.
💡Основное:
- Структуры не всегда ускоряют работу приложения, а не редко замедляют ее и увеличивают размер бинаря.
- Карта линковки (Link Map) позволяет посмотреть из каких сущностей состоит итоговый бинарь,
- С помощью LinkMap можно узнать размер сущностей, вырезанные символы, которые не используются в итоговом бинаре и являются кандидатами на удаление из кода, анализировать краши без DSYM.
- Для сохранения Link Map в файл необходимо включить настройку
- Имена символов манглированы, нужно деманглировать с помощью
- Чем больше вложенность структур друг в друга, тем больше будет итоговый размер структуры. Обычно особенно проблемными являются компоненты дизайн-системы.
- Использование экзистенциальных контейнеров дополнительно увеличивает размер за счет создания сервисных методов witness table. То есть, если компилятор не может рассчитать конкретный тип, а ходит через протокол - ситуация ухудшается. Вот почему нужно использовать some/generic везде, где это возможно.
- Флаги оптимизации -O никак не влияют на рост размера структур.
- Необоснованный рост может быть в КБ, десятки и сотник КБ, и даже МБ для особо больших структур.
- Накладные расходы на поддержку работы структур от 2 КБ превышают расходы на использование ссылочных типов
- Добавление
- Для определения того, какие структуры наиболее важны для такого рефакторинга можно построить граф вложенности структур (на основе Xcode index Store) и определить метрику центральности графа (Betweenness)
🧠 Мысли после доклада:
- А что там со SwiftUI? Вьюшки с кучей проперти-врапперов разгоняют размер и снижают скорость? Имеет ли смысл дробления вьюшек на более мелкие не только ради переписовок, но и облегчения размера?
- А что с NonCopyable структурами? Они не копируются и возможно в них нет такого большого количества сервисного кода.
- Как именно выглядят дженерики в итоговом файле - требует дополнительного изучения.
🔗 Ссылки:
- Видео (если у вас есть билет на конференцию)
Один из лучших докладов на Mobius 2025 Autumn. Очень люблю, когда докладчик копает глубоко, объясняет хорошо и разочаровывает меня в Swift.
💡Основное:
- Структуры не всегда ускоряют работу приложения, а не редко замедляют ее и увеличивают размер бинаря.
- Карта линковки (Link Map) позволяет посмотреть из каких сущностей состоит итоговый бинарь,
- С помощью LinkMap можно узнать размер сущностей, вырезанные символы, которые не используются в итоговом бинаре и являются кандидатами на удаление из кода, анализировать краши без DSYM.
- Для сохранения Link Map в файл необходимо включить настройку
Build Setting → Linking - General → Write Link Map File. Файл будет сохранен в Derived Data с именем {Имя_таргета}-LinkMap-normal-arm64.txt.- Имена символов манглированы, нужно деманглировать с помощью
swift demangle '{Имя_символа}'- Чем больше вложенность структур друг в друга, тем больше будет итоговый размер структуры. Обычно особенно проблемными являются компоненты дизайн-системы.
- Использование экзистенциальных контейнеров дополнительно увеличивает размер за счет создания сервисных методов witness table. То есть, если компилятор не может рассчитать конкретный тип, а ходит через протокол - ситуация ухудшается. Вот почему нужно использовать some/generic везде, где это возможно.
- Флаги оптимизации -O никак не влияют на рост размера структур.
- Необоснованный рост может быть в КБ, десятки и сотник КБ, и даже МБ для особо больших структур.
- Накладные расходы на поддержку работы структур от 2 КБ превышают расходы на использование ссылочных типов
- Добавление
indirect для enum зачастую лечит проблемы, когда в качестве associated value используется "дрянная структура".- Для определения того, какие структуры наиболее важны для такого рефакторинга можно построить граф вложенности структур (на основе Xcode index Store) и определить метрику центральности графа (Betweenness)
🧠 Мысли после доклада:
- А что там со SwiftUI? Вьюшки с кучей проперти-врапперов разгоняют размер и снижают скорость? Имеет ли смысл дробления вьюшек на более мелкие не только ради переписовок, но и облегчения размера?
- А что с NonCopyable структурами? Они не копируются и возможно в них нет такого большого количества сервисного кода.
- Как именно выглядят дженерики в итоговом файле - требует дополнительного изучения.
🔗 Ссылки:
- Видео (если у вас есть билет на конференцию)
👍14❤6🔥4🤔2
Мы уже видели, как Swift успешно захватил server-side, linux и windows разработку. В версии 6.3 язык делает очередной шаг уже в сторону разработки автономного программного обеспечения, в частности под микроконтроллеры или мини-пк, вроде Raspberry Pi и Arduino.
Embedded Swift - это строгое подмножество Swift, благодаря которому конечные бинарные файлы смогут иметь небольшой размер. Ограничения конечно существенные, но не фатальные: нет полноценных экзистенциалов, кучи типов стандартной библиотеки (например
Codable, KeyPath ...), рефлексии, weak и unowned и всякого разного, что может вызывать неопределенности в итоговом бинарном файле и увеличить его размер.Писать на нем iOS-приложения не получится, но использовать структуры, классы, перечисления. дженерики, протоколы, опционалы и другие возможности языка, но для создания микропрограмм - очень заинтересовало.
Неочевидным плюсом этого является то, что аттрибут
@_cdecl наконец зафиналили под именем @c (хотя может это было сделано и в более ранних версиях?). Когда я был в ВК, мы активно использовали его, так как взаимодействие C++ со Swift шло через C-слой (еще до официального интеропа). Ну и всякие новые аттрибуты, вроде @section и @used, Больше всего заинтересовала поддержка разработки под микроконсоль Playdate (см. картинку у поста). И это именно то, что потенциально будет интересно для детей (мужчин в возрасте до 50): пилить игрули не на чистых сях, а на смузи Swift в Xcode с запуском эмулятора Playdate.
🔗 Почитать про Embedded Swift
🔗 Посмотреть PlaydateKit
🔗 Ограничения Embedded Swift
#swift #embeddedswift #swift63
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11🤡3😁2