Comments 13
Apple хорошо бы провести оптимизацию компилятора, линковщика и всей системы сборки, а не гнаться за «революционными» изменениями в UI и прочими «инновациями», процессорами на 1% быстрее и 0.5% тоньше и т.п.
Был у меня коллега-индус, а у него друг-индус, работающий в Apple — так тот очень чертыхался, что в Apple никто не хочет браться за фикс даже критичных старых багов — руководство по голове не погладит, всем все равно. Вот если делаешь что-то, что пойдет на WWDC — сразу и премии, и карьерный рост, и прочие атрибуты хорошей жизни.
У меня на одном проекте секунд 20-30 проходило и то я страдал, а тут минуты… десятки минут… сочувствую всей iOS-девелоперской душой.
P.S. Я правильно понял, что чем больше либ на objc содержит твой podfile, тем хорошо если квадратично больше время запуска дебаггера? К сожалению, в каждом втором приложении нужна интеграция с Facebook и Google-либами, а они сплошь и рядом Objc на Objc и Objc погоняют.
Apple хорошо бы провести оптимизацию компилятора, линковщика и всей системы сборки
Им некогда, надо скорее выкатить новые апи на новые айфоны.
Да и для самих Apple — реально, в больших проектах поправил строчку, нажал перебилд — и открываешь браузер, потому что ждать долго. Быстрее выходят апдейты — быстрее платят юзеры — больше денег. Уверен, на дистанции зарплаты тех ребят окупятся сторицей, а уж сколько нервов можно сэкономить разработчикам…
мечты, мечты…
Некогда странно слышать, когда мы говорим о компании с капитализацией в миллиарды.
Да, сложная, муторная работа, но какая полезная для сообщества.
Корпорацию всегда больше волнует то, насколько работа полезна для капитализации, чем насколько она полезна для общества. Для неё это просто приятный бонус в карму. Люди платят деньги за полезную работу и не платят за бесполезную, а не наоборот: если платят, то работа получается полезная, а если не платят — то приходится делать бесполезную работу.
Аналогично, у корпорации всегда будут расходы, а также приемлемый уровень этих расходов. Замена разработчиков, отхвативших нервный срыв — это не проблема, а просто расходы, когда люди в очередь стоят за большой честью работать на вас. И готовы сами платить за право причаститься к благодетели App Store.
Просто зависимость эта не такая явная, как от новых «революционных» фич, и проявляется на длинной дистанции. Если долго забивать на такие вещи, то получим Nokia, или архитектуру MS Windows, да мало ли еще примеров — просто не так быстро.
Джобс об этом думал, поэтому и был Джобсом, а что там сейчас — одному индийскому богу известно
а уж сколько нервов можно сэкономить разработчикам
ну, меня в целом удивляет отношение яблок к разработчикам — все сделано так чтобы разработчик, который не пользуется Xcode — страдал. А если пользуется, то страдал от Xcode эксклюзивно от Apple™. И я совершенно не понимаю почему такая крупная кампания продолжает публиковать обновы по принципу ХХП. Казалось бы, за легаси они почти не держатся, в отличие от тех же MS, бета версии отдают покатать, только почему-то критичные баги выливают в стабильной версии системы.
Обычно, все потенциально полезные изменения Xcode кроются под "Stability improvement" в "Что нового", которое значит почти все что угодно — от "мы пофиксили тот баг с подсветкой скобочки которую вы просили в версии 5 в 2007 году" до "мы накинули вам +5 минут к запуску вашего приложения, чтобы вы успели сходить перекурить, пока течёт (по памяти) наш отладочный кетчуп". Мне кажется они платят своим разрабом кучу бабла только для того чтобы те прикинулись фрилансерами, сделали новую фичу в кодовой базе или пофиксили один баг при помощи костыля и не отсвечивали.
P.S. Кстати, я пришел в iOS разработку в 2009 году, был еще xCode 3 :) IB еще был отдельным приложением, с 4-й версии году в 10-м они сделали его уже встроенным
Я правильно понял, что чем больше либ на objc содержит твой podfile, тем хорошо если квадратично больше время запуска дебаггера?
Не совсем так, взрывной рост флажков
clang-а вызывает как раз рост количества Swift-модулей, а не ObjC. Как можно понять из нашего локального решения, позволившего смягчить проблему, если бы у вас был один Swift-модуль на все приложение, описанное в статье на вас бы не повлияло :)Тем не менее, это не делает ваше наблюдение неправильным, ведь у
cocoapods своя атмосфера. Вот пара фактов:1. Даже если под написан только на
Swift без примесей ObjC, поды добавляют к нему сгенерированные заголовок и m-файл.2. Каждому поду в header search paths записываются пути поиска до всех остальных подов, вне зависимости от того, от чего он на самом деле зависит (простите за каламбур).
Вследствие этих фактов получаем такую картину: допустим, у нас были поды
A, B, C, все на Swift. Поды сгенерируют проект таким образом, что, в числе прочих, у Swift-модулей будут такие флажки:A: -Ipath/to/B -Ipath/to/CB: -Ipath/to/A -Ipath/to/CC: -Ipath/to/A -Ipath/to/BТеперь мы хотим добавить еще один под
D, и картина будет выглядеть уже таким образом:A: -Ipath/to/B -Ipath/to/C -Ipath/to/DB: -Ipath/to/A -Ipath/to/C -Ipath/to/DC: -Ipath/to/A -Ipath/to/B -Ipath/to/DD: -Ipath/to/A -Ipath/to/B -Ipath/to/CИ, таким образом, количество флажков возросло с 6 до 12 (в асимптотике тут будет квадратичный рост: всего их будет
N * (N - 1)). Напомню, что, как мы уже выяснили в статье, все эти флажки склеятся, несмотря на то, что они дублируют друг друга.Давайте добавим еще один под
E, но уже на ObjC. Для него не будет Swift-модуля, пагубным образом влияющего на дебаггер, поэтому картина будет такая:A: -Ipath/to/B -Ipath/to/C -Ipath/to/D -Ipath/to/EB: -Ipath/to/A -Ipath/to/C -Ipath/to/D -Ipath/to/EC: -Ipath/to/A -Ipath/to/B -Ipath/to/D -Ipath/to/ED: -Ipath/to/A -Ipath/to/B -Ipath/to/C -Ipath/to/EКоличество флажков возросло с 12 до 16, но, если бы модуль
E содержал Swift (или был бы полностью на нем, это уже никакой роли не играет), то мы бы увидели не 16, а целых 20 флажков (т.к. добавилась бы еще такая же строчка для E).tl;dr: количество флажков при использовании подов растет как
M * N, где M — количество подов, использующих Swift (неважно при этом содержат ли они ObjC), а N — общее количество подов (причем во всем этом учитываются не только те поды, которые вы используете непосредственно в вашем приложении, но и их зависимости, которые вы, возможно, напрямую не используете). Таким образом, как ни парадоксально, чем больше доля подов на чистом ObjC, тем меньше взрыв флажков при сборке контекста дебаггера.И также — я очень люблю все продукты Apple, но у них есть 2 отстойных продукта — xCode и Apple developer portal (который сейчас developer.apple.com и appstoreconnect.apple.com). Еще iTunes был тем еще Nero burning rom, но слава богу RIP, больше не надо.
Прошло 10 лет, ничего в целом не изменилось.
Помню, как году в 2013 мне ньюкамеры в iOS, особенно дизайнеры, религиозники от Apple, лили в уши — это же Apple, скоро допилят, это же Apple, это все временно. Я тогда усмехался — как же, допилят. Воз и ныне там, к сожалению…
Спасибо за статью. Сколько у вас -F путей? У нас похожая проблема с lldb выглядела так: если побенчмаркать инструментами lldb-rpc-server и посмотреть с "Invert Call Tree", то выглядело так, что большую часть времени занимал stat$INODE64.
Кажется реальная причина была в том, что компилятор идет и для каждого прилинкованного через -framework или автолинкинг фреймворка для каждого -F делает походы на диск. Подозреваю, что в случае если у фреймворка еще есть clang модуль, то компилятору еще нужно пройтись по header'ам и скомпилировать pcm, если его нет в кеше. Нам помогло порезать search paths до ненужных header'ов и сложить все фреймворки в 1 папку, указав единый -F.
Как у вас выглядит инвертированный трейс?
Как мы ускоряли работу отладчика Swift