Если асинхронный метод выполняется синхронно, то возникают следующие издержки в использовании памяти: для методов async Task издержек нет, а для методов
async Task<T>
перерасход составляет 88 байт на каждую операцию (для платформ x64).
Не совсем, у обычного таска тоже есть оверхед. Потому в .NET Core появился ValueTask (да, не дженерик).
Нет не будет одинаковым. Из-за уязвимости, блок будет сохранен в первоначальном варианте [1,2,3,4,5,6], то есть в другом месте добавлена проверка на этот случай. Ведь имея [1,2,3,4,5,6] нам все равно придется достраивать его до полного дерева, а значит получиться в конечном итоге [1,2,3,4,5,6,5,6]. Вот только если отправить в блокчейн [1,2,3,4,5,6,5,6], то это будет означать, что транзации 5,6 были потрачены два раза, а мы должны это исключить. Поэтому мы не храним повторяющиеся транзакции в блокчейне, а дерево мы достраиваем по мере необходимости. Пусть меня поправят коллеги, если я не прав.
Попробуйте BenchmarkDotNet. Я уверен что он даст гораздо более точные результаты, к тому же он удобен и у него большой функционал. Ну и замерять в Debug режиме смысла много нету, так как финальное приложение в любом случае будет работать в Release.
Я был на севере (Гроннинген), там со вторника, числа 15, было + 13. Мне из солнечной Болгарии из +30 как-то холодно было. Это не говоря о том, что постоянное дует ветер. А целый день хоть и светло, но солнца совсем не было видно. Как вернулся обратно, заболел, собственно всю прошлую неделю провалялся больным дома.
Диалог выглядит как полноценное воссоединение семьи, я думаю можно смело подавать на визу :D
А если серьезно, ездил в командировку неделю назад в Нидерланды, климат совсем не понравился. Люди довольно сдержанные(я бы сказал холодные), что довольно хорошо в проффесиональном плане, но не в личностном.
Хотелось бы увидеть статью об Нидерландах если есть возможность.
1. Локализовать на английском
2. Выставить исходни локализации на гитхаб
3. Принимаем пуллреквесты от людей желающих локализовать для своего родного языка
4. Профит
P.S. Если смотреть правде в глаза, то локализации на английском языке будет более чем достаточно
Не совсем понял суть задачи. Если дело в организации хранения, то было бы неплохо организовать хранение всех менеджеров пучками(группами). Из моей практики, выглядит как довольно подходящий кейс для использования AzureTable. Там как раз можно организовать такое хранение. Плохо то, что там индекс как таковой, только один, и он распространяется на PartionKey, что в данном случае является регионом. А если у вас критерии организации данных постоянно меняются, то это точно не ваш случай. А и зачем вам два микросервиса? Один достает данные другой обрабатывает?
Ну про СУБД вы немного заблуждаетесь, на малых объемах данные её возможно будет достаточно, но как только данные станут более существенны прибегают к созданию ещё одной подобной БД — OLAP. При этом проектируют её оптимизированной под специальные запросы.
Ну если вам надо дергать данные с разных хранилищ, то тут ничего не поделаешь, придется делать несколько запросов. Есть конечно вариант хранить все же данные в SQL, но тут необходимо придерживаться нескольких правил, не должно быть связей между таблицами по вторичному ключу у разных сервисов, а также они должны быть с разными схемами. Так можно будет легко разделить данный на две различный базы, если того потребуется.
Если вы про организацию хранилища, то да, это EventSourcing. Тут правда надо понимать что хранилищем может быть и обычная SQL база, тут дело в самом подходе его организации. Насчет Saga паттерна можно почитать здесь.
Есть такая вещь как распределенная транзакция. Но это требует определеногго подхода и при проектировании хранилища. Идея в том, что сервис сохраняет текущее состояние, и ждет подтверждения от другого сервиса(кому было передано сообщение), что и он отработал успешно. Если такое подтверждение получено не будет то будет послано новое сообщение, которое отменяет предыдущее действие. Есть и специальные паттерны для выполнения таких транзакций, например Saga.
Поскольку проект под лицензией MIT, можно попробовать прогнать статический анализатор PVS-Studio, может ещё какие нибудь недочеты можно будет устранить.
Я вот установил на старый ноутбук Fedor-у с GNOME интерфейсом. Первое что не привычно так это отсутствие иконок на рабочем столе, знаю что можно это настроить, но было не до этого. Поигрался с установкой пакет, кажется собирал electrum приложение, ну и несколько раз натыкался на ошибку отсутствия нужных зависимостей в репозитории. Неприятно и проходиться искать нужные зависимости самому. Насколько я понимаю, репозитории федоры проходит модерацию прежде чем попасть туда, так и должно быть. Уязвимости нам не нужны! Как у остальных дистрибутивов с пакетными менеджерами и зависимостями? Потому как собираюсь ставить .net core, а по моему только в 26 версии собираетcя.
Не совсем, у обычного таска тоже есть оверхед. Потому в .NET Core появился ValueTask (да, не дженерик).
А если серьезно, ездил в командировку неделю назад в Нидерланды, климат совсем не понравился. Люди довольно сдержанные(я бы сказал холодные), что довольно хорошо в проффесиональном плане, но не в личностном.
Хотелось бы увидеть статью об Нидерландах если есть возможность.
2. Выставить исходни локализации на гитхаб
3. Принимаем пуллреквесты от людей желающих локализовать для своего родного языка
4. Профит
P.S. Если смотреть правде в глаза, то локализации на английском языке будет более чем достаточно
Ну если вам надо дергать данные с разных хранилищ, то тут ничего не поделаешь, придется делать несколько запросов. Есть конечно вариант хранить все же данные в SQL, но тут необходимо придерживаться нескольких правил, не должно быть связей между таблицами по вторичному ключу у разных сервисов, а также они должны быть с разными схемами. Так можно будет легко разделить данный на две различный базы, если того потребуется.