Pull to refresh

Comments 44

Во-первых, почему в опросе нет варианта «не использую»?
Во-вторых, в С++ и С# тернарный оператор ленивый и вычисляет одно выражение. Зачем его использовать, если необходимо вычислять ветки заранее?
Использовать, когда оба операнда представлены простыми логико-арифметическими операциями.
1. Вариант 'воздержался'.
2. Есть предположение, что Swift оптимизирует предварительное вычисление. Проверю в следующей статье.
Скорее оптимизируются проверки операндов на NULL и прочие исключение. Повертите ручки, отключающие оптимизацию — они должны сильно ускорить компилятор.
Простите, это как? После стольких лет развития компиляторов они не могут распарсить длинное (да не такое уж и длинное) выражение??? Почему аналогичное выражение на С/С++ (да и на любом другом языке) парсится без каких-либо проблем?
Кто там у них компиляторы пишет?
UFO just landed and posted this here
А потом расстрелять.
UFO just landed and posted this here

Я почему-то подозреваю, что трабл у них начинается не при парсинге выражения, а на стыке вывода типов и разрешения перегрузок. Но то, что ребята не освоили какого-нибудь Хиндли-Милнера, не извиняет их.
Кстати, может чего упустил, но вроде эта проблема была ещё во 2-й версии, и её клятвенно обещали пофиксить.

Мои наблюдения, не подтвержденные никакими исследованиями, говорят о том, что проблемой является вывод типов. Причём, дело не только в выводе дженериков по возвращаемому значению (как я понимаю, процесс трудоемкий, потому эта фича в «классических» языках отсутствует), но даже в числах, ибо числовые литералы в Swift не имеют типа, тип определяется исходя из контекста (такого в «классических» языках тоже нет). Как-то так выглядит проблема с моего дивана.
Что именно понимается под выводом Дженериков по возращаемому значению? Разве весь Linq в C# на этом не работает?
Имеется ввиду не тип возращаемого значения делегата, а тип возвращаемого значения самого метода наример. Если написать метод с дженерик возвращаемым типом и без параметров, то в C# при вызове прийдется явно указывать этот тип, даже при присваивании результа в переменную с конкретным типом. Swift же умеет выводить такие типы. Сюдаже, кстати, можно отнести перегрузки по возвращаемым типам, которы тоже встречаются нечасто, как правило, перегрузки работают только по параметрам.
var res = items.Select(o => new Tuple<string, int>(o.Value.ToString(), o.Value));


Метод Select<T>() — дженерик. Возвращаемое значение вычислено — IEnumerable<Typle<string,int>>. Или вы про что-то другое?

Тут возвращаемое значение метода Select вычисляется благодаря параметру типа Func<T, Tuple<string, int>. Я же говорю о следующей ситуации:


public interface IMessage
{
    string Text { get; set; }
}

public static class MessageFactory
{
    static T Create<T>(string message) where T: IMessage, new()
    {
        var result = T();
        result.Message = message;
        return result;
    }
}

Для вызова метода Create необходимо явно указать тип в самом вызове:


var message1 = MessageFactory.Create<SimpleMessage>("Hello world")
SimpleMessage message2 = MessageFactory.Create<SimpleMessage>("Hello world again")

Swift, в свою очередь, позволяет сделать следующее:


protocol Message {
    init()
    var text: String { get set }
}

class MessageFactory {
    static func create<T: Message>(text: String) -> T {
        var result = T()
        result.text = text
        return result
    }
}

let message: SimpleMessage = MessageFactory.create(text: "Hello world")

Как видите, тип не фигурирует в вызове, только в объявлении переменной. То есть, в данном случае, компилятор не тип выражения выводит исходя из того, что возвращает функция, а тип возвращаемого значения выводит из того, в каком выражении участвует вызов.

Насколько я понимаю, тут вся фишка в возможности наследования для анонимных типов, которой нет в C# (а жаль)
Это явно не парсер, а оптимизатор трудится. Судя по времени — делается полная проверка кода, формирующего операнды. Как гипотеза — на предмет, могут ли операнды вызвать исключение.
Оптимизация отключена. Вы же о флаге -Onone?
я никогда не работал с Swift, просто в свое время участвовал в нескольких простых компиляторах. Парсер просто не может занимать такое время. Чуть выше Johan выдал весьма правдоподобную гипотезу о выводе типов. Это тоже в некотором смысле оптимизация, можно было скомпилировать ветки для всех возможных типов. А пытаться понять, какие именно типы аргументов возможны — это реально долго.
А где тюнинг компилятора? Я думал вы исходники поправите самого компилятора, а не свои исходники.
Swift3 компилятору всего один год, как и парсеру. Некоторые проблемы существуют, но они не критичные, особенно учитывая что файлы уже собранные не пересобираются. Сборка во время разработки инкрементальная. Поэтому это всё «всплывает» при сборке проекта «с нуля». Если сильно раздражает — добро пожаловать в список котрибьютеров: https://github.com/apple/swift
чтоб контрибутить в свифт, не нужно быть работником Apple. Swift — опен сорсный проект. Пишите — создавайте PR.
Swift уже давно на совести open source сообщества. (https://swift.org)
Давайте будем честны, если открыть последние пулреквесты, то там только 1 или 2 человека не сотрудники apple.
А разве это не логично? Apple — первые из тех кто заинтересован в развитии языка.
Теперь продолжим игру в честность — у вас ведь есть возможность внести свой вклад? Так почему вы этого не делаете?
А я говорю, что это плохо? Я говорю, что swift развивают люди за зарплату Apple. Вот такая «совесть open source сообщества».

И да, это логично, потому что чтоб контрибьютить в такие проекты нужно обладать огромным количеством знаний и времени. Мало кто будет делать это бесплатно.

Собственно я от этой контрибуции не получаю никакой выгоды, поэтому этим и не занимаюсь.

Так вот инкрементальная сборка срабатывает только для изменений внутри метода. А если добавляешь новый метод или еще что, то собираются вдобавок и зависимые файлы повторно. Это самое грустное отличие от Obj-C. Фаст-пруф.


Кроме того, он еще и баганутый.


Тем не менее, спасибо за ответ. Инкрементальную компиляцию рассмотрю в одной из следующих статей.

он пересобирает только изменившийся файл, а не весь проект — это хорошо.
Инкрементальная не срабатывает при изменении параметров компиляции, это не проблема самого механизма инкрементальной сборки, это проблема XCode.
Если собирать с командной строки, такого не будет.
К сожалению, разрабатываем мы именно в Xcode. Сам регулярно сталкиваюсь с проблемой, что собирается больше, чем один файл. Постараюсь разобрать вопрос инкрементальной компиляцией в следующий раз.
Так я не предлашаю вам отказаться от XCode, просто swift — это отдельный проект, от икскода не зависящий. А статья называется «тюнинг компилятора». Ну и вы пишите что это проблема компилятора.
Понял о чем вы. Да, согласен.
Я старался подобрать не сложное название, чтобы было понятно в целом суть. Подумаю над тем как можно переименовать.
Спасибо за статью… Теперь я понимаю, почему мой проект долго собирается… И дело вовсе не в подах(((

Рекомендую использовать Carthage вместо Cocoapods, где это возможно.
Есть даже перевод их туториала.

Как раз хотел спросить. Я сам прихожу к тому чтобы использовать Carthage вместо Cocoapods. Но какой плюс с точки зрения сборки проекта? Например, в XCode поды собираются один раз, а пересобираются только после clean.
А Carthage пересобирается только после прямой команды.
Clean не триггерит пересборку зависимостей у него, это большой плюс, так как периодически приходится делать полную очистку.

Краткая суть Carthage — он собирает предварительно framework из твоей зависимости(чем-то похоже на флаг !use_frameworks в Cocoapods), а потом достаточно ее просто подключить к проекту.
Да, я пользовался Carthage и кроме этого плюса я пробую найти еще.
Другой наверное (но небольшой) — XCode'у не приходится индексировать исходники подов (и в Quick Open они не показываются)
Но, может быть кто-то замерял, с чем быстрее идет инкрементальный билд (в случае когда поды собраны): с carthage или cocapods
Вообще материал занимательный и полезный, но:
1. Пример с вычислением размера — такие упрощения в коде полезно делать не только для ускорения компиляции, но и для лучшей читаемости.
2. Уже конечно давно принято винить Apple во всем от глюков Xcode и убийства Кеннеди до неудачного расположения города Помпеи, но если все так плохо с инструментарием предоставленным Apple, то почему не используете Xamarin и ему подобные?
1. +1
2. Много альтернативных платформ пробовали, объем third-party фреймворков там значительно меньше, чем у нативной разработки. Как следствие, помощи в гугле тоже меньше.
Если отходить от Xamarin и говорить в общем, то еще вылезают сложности с оптимизацией. Часто бывает, что сам движок добавляет ощутимый overhead, который никак не разгонишь.

Пока яблочное зло — наименьшее. Периодически еще тыкаемся в Appcode, но разочаровываемся. Надеюсь, Jetbrains подтянут его.

Но то что яблоки лучший вариант на рынке, это не значит, что так должно быть! Я параллельно разрабатываю backend на Java/Kotlin, так там вообще практически не к чему придраться. Такого качества я жду от Apple.
Но то что яблоки лучший вариант на рынке, это не значит, что так должно быть!

Вот тут пожалуй плюсану. За последние три года качество продуктов Apple резко упало вниз.
Скажу по секрету, Xamarin почти не избавляет от проблем эпловких тулов, потому что сам через них работает. К тому же добавляет свои проблемы.
Правило следующее: у компилятора вызывают запор выражения с несколькими сложными слагаемыми. То есть теми, которые не просто являются переменными, но и выполняют какие-либо действия. А вот складывать переменные можно сколько угодно.

Вспомнилась проблема с производительностью в генераторе парсеров ANTLR. Там она как раз была связана с большим количеством однородных выражений при использовании леворекурсивных правил (пример с конкатенацией для Java.g4 грамматики: ManyStringConcatenation.java). Для решения этой проблемы такие правила нужно было переделывать, что выглядело не очень красиво и удобно. У результирующего парсера также появлялись проблемы с производительностью и при полном отказе от использования леворекурсивных правил. Если кому-то интересно, то о решении этих проблем я писал в своей статье о теории и практике парсинга исходников с помощью ANTLR и Roslyn в разделе Java- и Java8-грамматики.


К счастью, в настоящий момент проблема с леворекурсивными правилами пофикшена в ANTLR, а исправление будет доступно с версии 4.6, в которой, к слову, появится еще и поддержка Swift-рантайма.


Интересно, в чем же заключается проблема текущей версии Swift парсера и как ее можно разрешить?

Sign up to leave a comment.

Articles