PDSW

Структуры данных, которые уже присутсвуют в библиотеке классов, отлично решают задачи заявленные перед ними. Но что делать, если понимаешь что придётся столкнуться с задачей, которая решается очередью с приоритетом? Здесь уже нет готового SDK, и придётся либо тянуть чужую реализацию (или целую библиотеку) себе в проект, либо всё писать самому на коленке. Давайте сравним хотя-бы в первом приближении на базе какой структуры данных оптимальнее, в плане скорости работы и используемой памяти, реализовать очередь с приоритетом. Попробуем понять, что нам больше подойдёт двусвязный список (LinkedList), массив, список (List) и SortedSet. В большинстве случаев список, будет универсальной структурой данных. Но так ли это будет и при решении нашей проблемы?

От переводчика: рекомендую к Вашему внимаию перевод статьи Reuben Bond-а Performance Tuning for .NET Core. Тут, пожалуй, описаны почти все последние инструменты dotnet, которые помогут вашим приложениям достичь новых высот производительности. Статья интересна ещё и ссылками, которые просто must read!

Кто-то из вас, возможно, знает, что я трачу все свое время на то, чтобы завершить разработку новой .NET библиотеки сериализации. Сериализатор, должен вам сказать, оказался очень сложным в реализации. Он должен быть надежным, гибким и быстрым, безупречным в работе. Я не буду убеждать вас, что библиотеки сериализации должны быть быстрыми - в этом посте это само собой разумеется. Вот несколько советов из моего опыта по оптимизации производительности Hagar. Большая часть этих советов применима к другим типам библиотек или приложений.

Что такое паттерн предохранитель?

При разработке приложений enterprise уровня нам часто приходится вызывать внешние сервисы и ресурсы. Этими службами могут быть сетевые папки, сервера баз данных или веб-службы. Всякий раз, когда мы обращаемся к этим сервисам, существует вероятность того, что проблема с сетью или самой службой может вызвать сбой нашей системы. Один из способов работы со сбоями вызываемой службы состоит в том, чтобы ставить запросы в очередь и периодически повторять попытки. Это позволяет нам продолжать обработку запросов, пока сервис снова не станет доступным. Тем не менее, если в сети или сервисе возникают проблемы, то такие попытки повторной отправки запроса не помогут восстановить службу, особенно если она находится под повышенной нагрузкой. Такие запросы могут нанести еще больший ущерб и помешать работе служб. Если мы знаем, что потенциально могут быть проблемы со службой, мы можем помочь решить некоторые проблемы, внедрив шаблон предохранитель в клиентском приложении.

Предохранители в нашем доме предотвращают выброс тока от повреждения приборов или перегрева проводки. Они работают, позволяя определенному уровню тока войти в систему. Если ток превышает пороговое значение, цепь размыкается, останавливая ток и предотвращая дальнейшее повреждение. Как только проблема будет устранена, предохранитель может быть сброшен, что замыкает цепь и позволяет электричеству снова течь. Паттерн автоматического выключателя использует ту же концепцию, останавливая запросы к ресурсу, если число отказов превышает определенный порог.

Динамические типы данных добавляют гибкости нашему коду, они позволяют использовать скриптовые языки программирования в среде dotnet, позволяют хитрым образом избавится от написания лишнего кода при работы с объектами через рефлексию и вобще мегакруты. Но с большой силой приходит большая ответственность, а за лишнее удобство приходится платить дополнительную цену. И цена здесь - это скорость работы. Об этом должен знать каждый разработчик платформы дотнет. Но вот из-за чего происходит замедление, и насколько сильно просаживается скорость работы это уже вопросы со звёздочкой. И если вам так-же интересно знать ответы на эти вопросы, прошу проследовать под кат.

Вы когда-нибудь пытались ожидать завершение выполнения задачи внутри блока lock на C#? Если Вам приходила в голову такая идея но никак не доходили руки до воплощения, то предлагаю не спешить. Во-первых компилятор не даст это сделать, а во-вторых у разработчиков dotnet есть другие возможности решать проблему блокировки раделяемых ресурсов в асинхронном коде. Предлагаю с ними ознакомится под катом.

Исходя из того что теперь вы знаете что такое авто-мок, хочу Вас обрадовать ещё одной штукой: AutoFixture - библиотекой разработанной Mark Seemann-ом которая предоставляет функционал автомока. О том как им воспользоваться и будет этот перевод статьи с блога автора.

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

Предисловие переводчика: если Вам хочется попробовать немного Machine Learning и не хочется выходить за пределы родного dotnet - Вы можете воспользоваться фреймворком Accord Net. Статья за авторством César Souza создателя вышеупомянутого фреймворка поможет сделать первые шаги в этом направлении и в качестве примера решить небольшую задачку при помощи алгоритма деревьев принятия решений.

Ещё хотел бы добавить замечательный перевод Андрея Будая проясняющий работу алгоритмов ID3 и C4.5 и математику стоящую за ними

Как можно отделить юнит тесты от механизма Dependency Injection? В этой статье описывается паттерн юнит тестов (unit test), называемый автомок (Auto-mocking Container). Его можно использовать для устранения проблемы хрупких тестов (Fragile Test), которые так часто происходят при создании тестируемой системы (system under tests - SUT) при помощи антипаттерна Мать объекта. На этот вопрос отвечает Mark Seemann.

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

Вспомним пример из предудущего поста. По нажатию на кнопку нужно вызвать длительную задачу. Так как наш код асинхронный, код длительной задачи нужно разместить в синхронном коде обработчика нажатия кнопки, для этого воспользуемся техникой sync over async. Т.е. просто дождёмся завершения асинхронной задачи при помощи метода taskName.Wait().

При работе в проектах связанными с ui-control или asp.net часто приходится работать с ресурсами доступными в локальном хранилище потока (thread-local storage TLS). К слову: такое поведение можно задать при помощи аттрибута [ThreadStatic] или класса ThreadLocal<T>. При обращении к ним из другого потока платформа dotnet выбросит исключение System.InvalidOperationException с текстом ‘The calling thread cannot access this object because a different thread owns it.'.

Представим себе ситуацию когда в каком-то win-form приложении нам по нажатию кнопки нужно вызвать долгоиграющую задачу. Очевидно, что нужно было-бы создать поток и в этом потоке выполнить эту задачу. Проблематично будет отобразить результат выполнения из созданного потока на UI - ведь ресурсы UI принадлежат одному потоку, а обращаемся мы к нему в другом. Это и есть та вышеописанная ситуация, когда мы столкнёмся с System.InvalidOperationException. Для решения этой проблемы нам придётся подружиться с контекстом синхронизации.