Короче говоря проблема в реализации Linq. Написал цикл с простым перемножением, протестировал в .net 4.7.1, .net Core 2.0 и в Unity Unity 2018.1.0f2 с настройками рантайма .net 4.x Equivalet / .net Standard 2.0 и получил абсолютно идентичные результаты.
Результат для меня довольно загадочный. Не вижу особых отличий между Linq и другим кодом чтобы он так тормозил (в сотни раз). Кто прояснит причину?
Жрет не сама юнити, а жрет модель программирования к которой Unity как фреймворк сподвигает разработчиков.
Вспомните старые приложения на дельфи которые висли при нажатии на кнопочку обновить, потому что UI тред блокировался пока идет ответ от базы.
В Unity все пользовательские скрипты отрабатывают в промежутках между кадрами. Чтобы получить ровные 60fps, нужно размазать нагрузку ровным слоем по всем промежуткам (~16мс) между кадрами. Это довольно сложно сделать. Соответственно чуть промахнулся — лови фриз.
Разница 5ms против 2100ms выглядит ну слишком странной.
может быть компилятор C# оптимизирует вызов метода Contains(1) в цикле, так как в нем константа?
я бы попробовал Contains(i)
Это не является проблемой электромобиля как класса, это является проблемой реализации.
Сталкивался с этой проблемой в электросамокате., надо шить мозги.
Долго не дерево создается, а долго BAML парсится, когда в коде создаешь контролы этого не происходит.
Но разговор был не о производительности, а о сложности разработки не тривиального UI на XAML и в коде.
Я все свои аргументы уже изложил, не хочу холиварить и повторяться, так что удаляюсь из обсуждения)
XAML это абстракция над кодом, как любая абстракция он имеет свою цену. Вариант на XAML всегда будет только медленее чем вариант в коде. Иногда значительно, иногда нет.
Он удобнее для описания UI только потому что система классов WPF дизайнилась под работу с XAML. Кроме того в сложных случаях код все равно удобнее, и это именно та причина по которой я отказался от XAML.
Проблемы производительности это вообще отдельный вопрос, наверняка майкрософт мог бы оптимизировать до преемлемого уровня. Но вот декларативную природу XAML оптимизировать для сложных случаев все равно не выйдет.
Там есть какие-то хитрости с XAML, который по-умолчанию встраивается в сборку в виде BAML (бинарно сериализованный), а можно заставить его стать CAML (компилированный). Сам не пробовал, но кажется это тоже может помочь.
Вовсе нет, попробовал все и пришел к такому варианту.
Разметка на Xaml провалилась также как в свое время визуальное программирование. Xaml не является языком программирования, как C#, он ограничен и создает проблемы которые потом героически решаются.
Это просто мнение, оно может быть полезно тем кто чувствует то же, но пока сомневается :)
Нет, не делают. Суть абстрактного класса в поддержке полиморфизма.
Полиморфизм создает проблему при множественном наследовании, поэтому можно наследоваться только от одного класса, но реализовывать множество интерфейсов.
Вы зря переживаете :)
Результат для меня довольно загадочный. Не вижу особых отличий между Linq и другим кодом чтобы он так тормозил (в сотни раз). Кто прояснит причину?
Вспомните старые приложения на дельфи которые висли при нажатии на кнопочку обновить, потому что UI тред блокировался пока идет ответ от базы.
В Unity все пользовательские скрипты отрабатывают в промежутках между кадрами. Чтобы получить ровные 60fps, нужно размазать нагрузку ровным слоем по всем промежуткам (~16мс) между кадрами. Это довольно сложно сделать. Соответственно чуть промахнулся — лови фриз.
может быть компилятор C# оптимизирует вызов метода Contains(1) в цикле, так как в нем константа?
я бы попробовал Contains(i)
Сталкивался с этой проблемой в электросамокате., надо шить мозги.
Рекуперация тут ни при чем. Покрышке без разницы причина появления тормозного усилия.
Но разговор был не о производительности, а о сложности разработки не тривиального UI на XAML и в коде.
Я все свои аргументы уже изложил, не хочу холиварить и повторяться, так что удаляюсь из обсуждения)
каждое создание контрола, описанного в XAML в рантайме приводит к парсингу его BAML, это доооолго
CPU и GPU вообще к теме не относится
Проблемы производительности это вообще отдельный вопрос, наверняка майкрософт мог бы оптимизировать до преемлемого уровня. Но вот декларативную природу XAML оптимизировать для сложных случаев все равно не выйдет.
Разметка на Xaml провалилась также как в свое время визуальное программирование. Xaml не является языком программирования, как C#, он ограничен и создает проблемы которые потом героически решаются.
Это просто мнение, оно может быть полезно тем кто чувствует то же, но пока сомневается :)
Не пользуюсь ни codebehind ни MVVM ни богомерзким XAML. Создаю UI в коде. Счастлив.
Полиморфизм создает проблему при множественном наследовании, поэтому можно наследоваться только от одного класса, но реализовывать множество интерфейсов.
Вы зря переживаете :)