Я, если честно, не смотрел asm код, но на каком основании оптимизатор должен был выкинуть вложенный цикл? Он эвристически в момент компиляции вычислил, что на каждой итерации внешнего цикла результат вложенного будет одинаковым и битовое 'или' также даст одинаковый результат? Он так не имеет права сделать, может я в другом потоке этот массив параллельно изменяю. В вашем примере просто операция вычисления остатка от деления на произвольное число сильнее нагрузило процессор, чем остаток от деления на 2, потому и накладные расходы Linq на этом фоне кажутся меньше. Замените в своём примере 'j % i == 0' на '(j+i) % 2 == 0', если так хотите, чтобы i участвовала. На моём компьютере 26 мс против 4мс. В любом случае, вы уже изменили алгоритм, а не оптимизировали, мне нужен был именно результат 1-го варианта, а не другой алгоритм.
Дело не в алгоритмической сложности, она же как раз не меняется, дело в лишних телодвижениях, которые тянет Linq (лишние вызовы методов, аллокации), в примере сверху разница на элементарной операции в ~6 раз. Фреймворки разные бывают, возможно в каких-нибудь вспомогательных функциях и используется, но точно не performance-critical (а в статье тег 'Высокая производительность'). Где-нибудь в ядре asp.net core или roslyn Linq врядли используется хоть в одном методе, который десятки тысяч раз в секунду выполняется. Понимать зачем, конечно, надо.
Может для CRUD и формочек разницы нет, но в разработке фреймворков и алгоритмов Linq однозначно нет. К примеру, можете заоптимизировать такой код?
Некоторый код
[Config(typeof(BenchmarkConfig))]
public class Benchmark
{
readonly int[] Values = Enumerable.Range(0, 5000).Select(i => i).ToArray();
const int OuterCount = 1000;
[Benchmark]
public int LinqBench()
{
var value = 0;
for (var i = 0; i < OuterCount; i++)
value |= Values.Where(j => j % 2 == 0).Sum();
return value;
}
[Benchmark]
public int ForBench()
{
var value = 0;
for (var i = 0; i < OuterCount; i++)
{
var sum = 0;
foreach (var val in Values)
if (val % 2 == 0)
sum += val;
value |= sum;
}
return value;
}
}
| Method | Mean | Error | StdDev |
|---------- |----------:|----------:|----------:|
| LinqBench | 22.458 ms | 0.0325 ms | 0.0476 ms |
| ForBench | 3.865 ms | 0.0186 ms | 0.0273 ms |
Однажды в моём пет-проекте понадобился парсер математических выражений и вместо того, чтобы написать простейший рекурсивный парсер, мне подумалось написать маленький велосипедик, который парсер сгенерирует. Тогда я ещё не осознавал, что это займет чуть больше времени, чем пару недель работы. Когда через год генератор уже работал, но, как оказалось, очень медленно, я решил всё-таки почитать книгу дракона. Потом уже жалко было бросать. Провёл работу по оптимизации, придумал свой язык описания грамматики, дописал генератор модели синтаксического дерева, добавил предикаты/действия в парсере/лексере, реализовал левую рекурсию, вызов правил внешних грамматик. На данный момент нет восстановления после ошибок и рекурсии в лексере. А так можно взять грамматику ANTLR и немного подправив синтаксис скормить генератору и получить парсер.
Некоторое время занимаюсь разработкой своего генератора парсеров на C#, по открытым грамматикам PL/Sql и C# получаются парсеры на 35к и 6.8к строк соответственно. Visual Studio с Resharper'ом вообще не в восторге от сгенерированного парсера PL/Sql
У меня Dell u3415w уже 4 года… сверху/снизу большие засветы. Внизу пластиковая панель от самого дисплея отошла на 3мм… нажатием на неё пальцем ощущается люфт на эти 3мм… теперь там пыль собирается. Стоил около 1000$, в целом доволен именно размером, работать одно удовольствие, но качество за эти деньги огорчило. На работе 2 монитора и без рамки всё же намного удобнее, особенно когда приложение развёрнуто на весь экран. В Visual Studio можно все панели разместить и полноценно работать с 2-мя документами одновременно при горизонтальном расположении. А вот с двумя мониторами уже 1 приложение на 2 монитора не так удобно работать. У меня в Visual Studio даже если окно с результатами поиска на другом мониторе, уже вызывает дискомфорт. 2 разных монитора — это как 2 разных контекста, между которыми нужно переключаться… для 2-х программ нормально, для 1-й неудобно.
Вы сейчас придумали оптимизацию, которая сэкономила на 1-м названии свойства для каждого объекта (Id). Зато сломали мозг пользователям, которые без вашего объяснения не будут знать, как править конфиг, а так же заставив разработчиков написать вручную десериализаторы для чтения таких конфигов т.к. я думаю ни в Java (для которой собственно и был пример приведён), ни в C#, ни в любом другом языке по умолчанию сериализаторы не будут знать о ваших оптимизациях.
Вы точно у меня хотели спросить? Я думал по моему комментарию очевидно будет, что я не фанат JSON от слова «совсем». Я согласен с комментатором ниже, что конфиг в JSON — злое зло. Мой выбор XML. И этот выбор применителен не только к описанию конфигурации.
К счастью, все это возможно в Typescript, потому что он поддерживает комментарии в JSON-синтаксисе.
Честно говоря, это похоже на ситуацию, когда лохматые гвоздики шурупы пытаются забивать молотком в гипсокартон. Т.е. вот даже из статьи вроде как выходит JSON появился на свет не как грамотно продуманное решение, а скорее как некий костыль для решения определенной задачи в условиях существующих на тот момент технологий (кстати отдаленно напоминает историю создания одного популярного языка программирования). Но сейчас в защиту преподносятся аргументы перед XML, такие как простота, выразительность, элегантность и т.д. Вот только незадача, не хватает комментариев и прочих вещей (может однажды и CDATA переизобретут), которые так нужны сейчас в решении несвойственных данному формату задач. Поэтому давайте доделывать всякие костыли, из которых, возможно, когда-нибудь получится XML. У меня всё чаще складывается ощущение, что я где-то пропустил свою остановку.
Если JSON использовать только как формат для обмена данными, то комментарии действительно не нужны. Но сейчас JSON используют везде, и где надо, и где не надо. Вот допустим описание конфигурации чего-либо. Если я хочу временно отключить часть конфигурации, то в XML я могу просто воспользоваться комментарием.
Я продлевал подписку на Resharper Ultimate + Rider 26 января, у меня на странице аккаунта есть цена Billing date: January 26, 2019 for US $107.00
(тут с учётом НДС для моей страны)
Сейчас с 50% скидкой выходят те же 107$. Получается подняли цену в 2 раза и сейчас предлагают скидку 50%? Отличный маркетинг.
Ну так если хвост списка определять путём пробега всего списка от головы и до, собственно, хвоста. Ничего удивительного, что вставка элементов в конец списка так затрагивает производительность. Тут бы указатель на хвост хотя бы иметь, ладно уже там колличество)))
Мне в такие моменты вспоминается спор (коих уже было много на хабре), а нужно ли программисту знать основы алгоритмов, структур данных и т.п. Вот можно добавить ещё, а нужно ли знание основ ИБ для создания охранной системы? Исходя из данной статьи, ответ следующий — нет, не нужно. Систему ведь сделали, она работает. С телефона сигнализацию можно включить/выключить, удобно же)))
Вы привели задачу для контрола выбора интервала дат в качестве примера как использовать MVVM и сейчас за уши притягиваете простоту восприятия. Для озвученной задачи, как я уже сказал выше, нужен Control, это не View модели, представляющей интервал дат. Так зачем на изначально некорректном примере доказывать правильность использования MVVM.
Вобщем, вступать в дальнейший спор (или продолжать) я не хочу.
Я задавал вопрос автору статьи про Codebehind и хотел выяснить разницу между VM и Codebehind. Вы же привели в пример конкретную задачу. Так вот элемент выбора интервала дат — это самостоятельный элемент управления, точно также как и DatePicker — элемент управления для выбора 1-й даты и они к MVVM вот вообще никакого отношения не имеют чуть более чем на 100%.
Если вы привяжетесь к одной какой-то модели, то эта привязка станет частью контрола, и использвоать в другом проекте вы его не сможете, не потащив за собой модель этого. Это очевидные вещи, да. Но вы почему-то о них спрашиваете.
Здесь я Вас уже перестал понимать, в контексте предложенной Вами задачи.
Я всё ещё не вижу проблемы. Вы говорите очевидные вещи, Codebehind — часть самого элемента, кто же спорит. Что означает, я буду её тащить всюду? Вы привели пример задачи, выбор интервала даты. Я Вам объяснил как её решить, и MVVM к этой задаче вообще не имеет отношения. Вот даже в этой задаче, скажем конечная дата не может быть меньше начальной. Вы это условие обеспечивать где собираетесь, Codebehind контрола выбора дат, или где?
Intel Core i7-5820K CPU 3.30GHz (Broadwell), 1 CPU, 12 logical and 6 physical cores
.NET Core SDK=3.1.300
[Host]: .NET Core 3.1.4 (CoreCLR 4.700.20.20201, CoreFX 4.700.20.22101), X64 RyuJIT
MediumRun: .NET Core 3.1.4 (CoreCLR 4.700.20.20201, CoreFX 4.700.20.22101), X64 RyuJIT
Job=MediumRun BuildConfiguration=Release Toolchain=.NET Core 3.1
IterationCount=15 LaunchCount=2 WarmupCount=10
| Method | Mean | Error | StdDev |
|---------- |----------:|----------:|----------:|
| LinqBench | 22.458 ms | 0.0325 ms | 0.0476 ms |
| ForBench | 3.865 ms | 0.0186 ms | 0.0273 ms |
Хотя Вам уже ответили, но вот 2 версии вашего конфига:
xml
json
Что в xml версии больше "шума", так это факт, я спорить не буду. Но лично мне xml версия больше нравится.
Честно говоря, это похоже на ситуацию, когда
лохматые гвоздикишурупы пытаются забивать молотком в гипсокартон. Т.е. вот даже из статьи вроде как выходит JSON появился на свет не как грамотно продуманное решение, а скорее как некий костыль для решения определенной задачи в условиях существующих на тот момент технологий (кстати отдаленно напоминает историю создания одного популярного языка программирования). Но сейчас в защиту преподносятся аргументы перед XML, такие как простота, выразительность, элегантность и т.д. Вот только незадача, не хватает комментариев и прочих вещей (может однажды и CDATA переизобретут), которые так нужны сейчас в решении несвойственных данному формату задач. Поэтому давайте доделывать всякие костыли, из которых, возможно, когда-нибудь получится XML. У меня всё чаще складывается ощущение, что я где-то пропустил свою остановку.(тут с учётом НДС для моей страны)
Сейчас с 50% скидкой выходят те же 107$. Получается подняли цену в 2 раза и сейчас предлагают скидку 50%? Отличный маркетинг.
Вобщем, вступать в дальнейший спор (или продолжать) я не хочу.
Здесь я Вас уже перестал понимать, в контексте предложенной Вами задачи.