Обзор Swift 3 компилятора и способы его ускорить. Часть 1.
Развенчание существующих мифов. Мнение о проблемах autocompletion в Xcode.
Предисловие:
Наша компания занимается разработкой мобильных приложений под ключ. Многие наши iOS разработчики говорят на Objective-C лучше, чем на русском, их девушка Cocoa, а спят они в обнимку с айфоном… и вот стали мы вдруг писать на Swift.
Я не буду говорить про различные косяки синтаксиса, веселые "Segmentation Fault: 11", периодически гаснущую подсветку, это все и так известно. Пусть больно, но терпимо.
Но есть кое-что по-настоящему убивающее бизнес, а не просто доставляющее дискомфорт. Медлительный компилятор. Да-да, это не просто громкий заголовок.
Когда одинаковые по объему Obj-C и Swift проекты собираются с четырехкратной разницей во времени. Когда при добавлении одного метода стартует пересборка половины всего кода. Когда ошибки компилятора вообще выводят его из строя — это настоящее убийство времени разработчика. А как известно: время — это деньги.
Есть два варианта: продолжить ныть и терпеть, либо решать вопрос. Мы выбрали второе.
Изобретение велосипеда
Перед тем как погрузиться по колено в Swift, мы предварительно пошуршали по просторам интернета на предмет уже существующих исследований этой тематики. К нашему счастью была найдена неплохая статья на русском и исходная на английском.
Так зачем же еще одну плодить? А затем, что, во-первых, все это было еще до третьего свифта, во-вторых, некоторые утверждения в статье не совсем верны, а так же список коварных мест было бы неплохо дополнить. Чем мы и займемся.
Материала тут не на одну статью, так что буду выкладывать постепенно.
Да и кроме самой скорости компиляции есть еще фактор производительности в runtime, который тоже надо бы осветить.
Начнем с того, что уже было известно, но просто проверим на актуальность в Swift 3.
Nil Coalescing Operator
Моя любимая фишка Swift, сахарный optional. Чем-то похож на nil-safe сообщения в Obj-C.
Возьмем пример из прошлых статей. Сейчас вы поймете, почему они не совсем корректны:
let left: UIView? = UIView() let right: UIView? = UIView() let width: CGFloat = 10 let height: CGFloat = 10 let size = CGSize(width: width + (left?.bounds.width ?? 0) + (right?.bounds.width ?? 0) + 22, height: height)
Время компиляции: 12 секунд! Приятель, у тебя третий пень что ли?
Даже хуже, чем было в Swift 2.2.
Хочется сказать: "Воу, Apple, что за?", но не спешите с выводами. Давайте немного оптимизируем этот код, разбив длинное выражение на несколько маленьких:
let firstPart = left?.bounds.width ?? 0 + width let secondPart = right?.bounds.width ?? 0 + 22 let requiredWidth = firstPart + secondPart let size = CGSize(width: requiredWidth, height: height)
Время компиляции: 30 ms. (миллисекунд)
Получается, дело вовсе не в злых optional?
Но нет, это было бы слишком просто. Давайте усложним задачу:
class A { var b: B? = B() } class B { var c: C? = C() } class C { var d: D? = D() } class D { var value: CGFloat? = 10 } ... let left: A? = A() let right: A? = A() let width: CGFloat = 10 let height: CGFloat = 10 // Опциональная ламбада! let firstPart = left?.b?.c?.d?.value ?? 0 + width let secondPart = right?.b?.c?.d?.value ?? 0 + 22 let requiredWidth = firstPart + secondPart let size = CGSize(width: requiredWidth, height: height)
Время компиляции: 35 ms.
Вывод: У Nil Coalescing Operator все стерильно, можно пользоваться.
Но тогда в чем же была проблема?
Уже не сложно догадаться, что корень зла таится в длинных выражениях. Автор русской статьи вскользь упомянул, что проблема с nil coalescing operator воспроизводится только в сложных операциях, но, к сожалению, не заострил на этом внимание.
Правило следующее: у компилятора вызывают запор выражения с несколькими сложными слагаемыми. То есть теми, которые не просто являются переменными, но и выполняют какие-либо действия. А вот складывать переменные можно сколько угодно.
Вы, наверное, скажете: "Где пруфы, Билли?"
Хорошо. Тогда возьмем предыдущий код, но не будем дробить его на под-операции:
let requiredWidth = left?.b?.c?.d?.value ?? 0 + right?.b?.c?.d?.value ?? 0 + width + 22 let size = CGSize(width: requiredWidth, height: height)
Результата долго ждать не пришлось (пришлось):
Цитирую, если не получилось прочитать со скрина: "Expression was too complex to be solved in reasonable time; consider breaking up the expression into distinct sub-expressions".
Перевод: "Выражение было слишком сложным, чтобы решить за приемлемое время. Разбейте формулу на отдельные под-выражения."
Ч.т.д.
Дальнейшее является наблюдением без теоретической базы.
Многие замечали, что в Xcode регулярно отваливается auto-completion. Это, как правило, происходит в момент фоновой компиляции. Если вы написали что-то вроде выражения, которое вызывает "Expression was too complex", то сразу за этим умрут и подсказки.
Это можно легко проверить. Возьмем тот же метод и начнем писать self.view, чтобы получить подсказку:
А потом добавим наше выражение-убийцу. Все, подсказок вы больше не получите, даже если усиленно лупить по ctrl+space:
Лечится это запуском явной компиляции и устранением ракового кода.
Идем дальше.
Тернарный оператор
В статье так же освещаются проблемы тернарного оператора. Время компиляции кода можно увидеть в комментариях:
// Build time: 239.0ms let labelNames = type == 0 ? (1...5).map{type0ToString($0)} : (0...2).map{type1ToString($0)} // Build time: 16.9ms var labelNames: [String] if type == 0 { labelNames = (1...5).map{type0ToString($0)} } else { labelNames = (0...2).map{type1ToString($0)} }
Кстати, у меня такого метода как type0ToString в SDK не нашлось. Я его заменил на упрощенный вариант, разницы никакой:
let labelNames = type == 0 ? (1...5).map{String($0)} : (0...2).map{String($0)}
Время компиляции: 260 ms. Пока все подтверждается.
Но мне кажется, что тернарный оператор несправедливо обвинен. Попробуем снова разбить формулу на отдельные выражения, но без использования if-else:
let first = (1...5).map{String($0)} let second = (0...2).map{String($0)} let labelNames = type == 0 ? first : second
Время компиляции: 45 ms
Но это не предел. Упростим еще больше:
let first = 4 let second = 5 let labelNames = type == 0 ? first : second
Время компиляции: 7 ms.
Вердикт: тернарный оператор оправдан.
Еще несколько амнистий
Операция Round():
// Build time: 1433.7ms let expansion = a - b - c + round(d * 0.66) + e
Время компиляции: 6ms
Сложение массивов:
// Build time Swift 2.2: 1250.3ms // Build time Swift 3.0: 92.7ms ArrayOfStuff + [Stuff]
Время компиляции: 19ms
И самое сладкое:
let myCompany = [ "employees": [ "employee 1": ["attribute": "value"], "employee 2": ["attribute": "value"], "employee 3": ["attribute": "value"], "employee 4": ["attribute": "value"], "employee 5": ["attribute": "value"], "employee 6": ["attribute": "value"], "employee 7": ["attribute": "value"], "employee 8": ["attribute": "value"], "employee 9": ["attribute": "value"], "employee 10": ["attribute": "value"], "employee 11": ["attribute": "value"], "employee 12": ["attribute": "value"], "employee 13": ["attribute": "value"], "employee 14": ["attribute": "value"], "employee 15": ["attribute": "value"], "employee 16": ["attribute": "value"], "employee 17": ["attribute": "value"], "employee 18": ["attribute": "value"], "employee 19": ["attribute": "value"], "employee 20": ["attribute": "value"], ] ]
Время компиляции: 86 ms. Могло быть и лучше, но уже хотя бы не 12 часов.
На этом первую часть хотелось бы закончить. В ней мы развенчали мифы об опциональном и тернарном операторах, сложении массивов и некоторых функциях. Узнали об одной из причин зависаний autocompletion, а так же выяснили, что компиляцию Swift больше всего тормозят сложные формулы. Надеюсь, было полезно.
В дальнейшем еще пройдемся по аспектам языка, в том числе проверим на быстродействие языковые структуры switch-case, if-else, guard и так далее.
Буду рад обратной связи. Пишите в комментариях, что разхабрать в первую очередь.
ссылка на оригинал статьи https://habrahabr.ru/post/316986/
Добавить комментарий