Да, это аналог. Вычисления скорости остаются, но можно убрать GetBytesAsync:
using (var handler = new ProgressMessageHandler())
using (var client = HttpClientFactory.Create(handler))
{
handler.HttpReceiveProgress += (s, e) =>
NetworkSpeed.AddInfo(e.BytesTransferred - lastRecorded);
// use client here to download file
}
Проблема заключается в том, что сами файлы Electron ASAR не зашифрованы и не подписаны, что позволяет изменять их без изменения подписи соответствующих приложений.
а причем тут Электрон? Насколько мне известно, подписанные библиотеки поддерживает только .net'овский рантайм, да и то, используется это не очень часто.
я же довольно ясно выразил свою мысль: проблема не в самом чтении, а в том, как считанные данные потом обрабатываются. "правильная" реализация создает списки, бессмысленные и бесполезные, захламляющие память и создающие нагрузку на GC (которые, кстати, еще и динамически растут, что приводит к перевыделениям памяти при создании каждого списка)
б) вы сами-то пробовали проверять?
у меня на самсунге 850 PRO (PCI-E 3.0) c тестовым набором в 43 128 файлов объемом 2.2 ГБ:
без кэширования (первый запуск): "правильная" версия: 27 сек. "неправильная": 23 сек
следующие запуски: "правильная" версия: 18 сек. "неправильная": 22 сек
Как видите разница в скорости небольшая и зависит от кэширования.
Зато "правильная" версия скушала 500мб RAM, а неправильная 0 (по крайней мере "на глаз" не удалось заметить выделений памяти)
А при увеличении объема правильная упала с Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
А вы не скажите какой вариант правильный не зная контекста
Вы правы, не скажу. Зато автор безапелляционно утверждает, что циклы — неправильно, приводит пример в разделе "Как не надо писать" с подписью про "упоротость".
По сути, он взял эффективный, но сложный алгоритм, обозвал его упоротым и переписал, подняв читабельность и пожертвовав эффективностью.
Чуть выше, RandomInternetPerson привел вариант с ленивым построчным чтением, что, ИМХО, в 80% типовых случаев будет оптимальным
И еще один неприятный сюрприз ожидает пользователей "правильной" версии, когда выяснится, что эта реализация падает с арифметическим переполнением, если в файлах, суммарно, окажется < 2,147,483,647 строчек, а sum умеет возвращать только Int.
При этом в "неправильной" версии можно использовать BigInteger
fun countLinesInFiles(fnames: List<String>): Int
= fnames.map { File(it).readLines().size }
.sum()
Эта реализация считывает все содержимое файлов в массив только для того, чтобы потом взять его размер, тогда как "неправильная реализация" читает посимвольно.
Вам стоит попробовать обе на папке с логами в пару гигабайт и подумать еще раз над тем, какая их них правильнее
Спасибо за маршрутчика, действительно все так :)
Но, вот все-таки, определение конкурентности и параллелизма, которые даются в статье, нуждаются в доработке.
Я бы так написал:
параллелизм:
в литературе: похожесть
в быту и академических кругах: одновременность
в геометрии: пересекаемость прямых
в программировании: вот тут поподробнее…
в общем-то, это слово уже вызывает некоторую путаницу. Я честно пытался гуглить, чтобы найти красивое определение в заслуживающем доверия источнике, но не нашел. Если вы сделаете тоже самое, то увидите, что найденные определения как-то подозрительно отличаются друг от друга. Не то чтобы сильно, но общее представление не складывается. Это корень проблемы, порождающей бесконечные споры и непонятки вокруг термина. Я запутаю его еще сильней :)
Для себя, я разделяю параллельность на машинную и алгоритмическую. Это мои собственные термины, так что можете не гуглить.
Машинная: одновременное выполнение блока машинных инструкций. Ну или «почти» одновременное (псевдопараллельность).
Алгоритмическая: никак не связана с инструкциями, процессорами и т.д. Мы просто выполняем несколько алгоритмов сразу. Это могут быть разные алгоритмы (параллелизм задач) или один и тот же, но с разными входными данными (параллелизм данных, SIMD)
Ключевой момент здесь — эти блоки инструкций или алгоритмы выполняются от начала до конца без остановки. В случае с «настоящим» параллелизмом, код выполняется на нескольких ядрах одновременно. В случае с псевдопараллелизмом, на одном, так что остановки есть, но они замаскированы и прозрачны для наблюдателя. В алгоритмическом случае мы вообще абстрагируемся от того, как что-то выполняется.
Конкурентность:
В бытовом и политическом плане: соперничество
В бизнесе и экономике: работы на одном рынке
В программировании: частный случай параллелизма
В машинном параллелизме рассматривается тема разделения времени выполнения потоков на доступные процессорные ядра: планировщик ОС выделает «кванты» времени каждому потоку по чуть-чуть, переключаясь между ними так, чтобы «никому не было обидно», как многодетная мать, которой важно, чтобы всем детям досталось ее внимание.
В алгоритмическом параллелизме мы по-прежнему абстрагированы от все этих процессоров. Вместо них рассматривается тема разделения каких-то общих ресурсов. В теории неважно, каких именно. На практике это могут быть файлы, открытые на запись, сетевые порты, периферийные устройства, которые не умеют работать параллельно или даже пользователь, которому надо показать несколько модальных окон или popup’ов, но не сразу.
В машинной конкурентности рассматриваются темы асинхронности и зеленых потоков.
В алгоритмической – примитивы синхронизации.
P.S. чтобы все запутать еще сильнее, можно упомянуть, что "просто" параллелизм и конкурентность не являются взаимоисключающими. Параллельно-конкурентное выполнение тоже возможно
Concurrency – это когда мы имеем дело со многими вещами одновременно, а Parallelism – когда делаем много вещей одновременно.
Сломал мозг в попытках понять разницу.
Водитель маршрутки, который рулит, принимает оплату, говорит по телефону и щелкает семки имеет дело со многими вещами одновременно или делает много вещей одновременно?
С этой мышкой я прошел пусть от девятиклассика до взрослого семейного мужчины :)
За это время ее заливали лимонадом, чаем, пивом, вином, напитками покрепче, по мере взросления и в силу жизни в студ. общежитии.
В какой-то момент времени, я уверовал, что она будет работать вечно, но случился дабл-клик.
Единственное, о чем жалею, что не замерил ее точное время жизни (~ 15 лет интенсивного использования).
За это время, матовая пластмасса, под местом соприкосновения с пальцами, стерлась до гладкой блестящей поверхности (с впадинами от трения пальцами).
Мои следующие мышки прожили максимум пару лет. Сейчас использую простую двухкнопочную logitech (уже пол-года, полет нормальный)
Стандартная библиотека, официальная библиотека от коммерческой компании и pet-project с гитхаба — все это, разные, с точки зрения надежности, библиотеки.
Выбор делается исходя из того, насколько критичный для бизнеса функционал разрабатывают.
Для финансовых организаций, валютные вычисления — это критичный функционал. Ошибки могут стоит репутации и больших денег.
При сложении/вычитании целых чисел с ошибками округления, ошибки складываются
При умножении некоторого числа с ошибкой округления на некоторый коэффициент ошибка также умножается на этот коэффициент.
Например, если у вас сумма получается умножением цены на количество, при этом цена получена с ошибкой округления до 0,5 копеек, то после умножения ее на 1000 литров (считаем цену за бензин, например) ошибка округления в сумме может достичь 50 рублей.
В DineroJs 78 файлов и 9 в папке src.
И добавлять их надо будет в каждый проект этой несчастной организации.
DineroJs использует import/export, не забываем, что NodeJS поддерживает модули экспериментально.
Так что нужно будет это собирать.
У вас старая версия Babel или вообщем его нет. что тогда?
И еще тесты тоже нужно будет добавлять.
И еще 29 зависимостей добавить в devDependencies.
Ok. Будете использовать Dinero.js , а там баг. Что тогда? Извольте заплатить за приватный репозиторий NPM, делать форк, переустанавливать пакеты в куче компонентов и поддерживать это все.
Искать альтернативы NPM?
Или может просить девушку из Франции, которая поддерживает этот проект, пофиксить баг и зависеть от ее настроение и занятости?
Что будет, если Евросоюз придумает новую валюту, а мэинтейнер в декретном отпуске и ей глубого наплевать на обновление проекта?
Вы готовы доверять стороннему NPM пакету денежный процессинг в организации? А ваш начальник?
Вы хотите использовать новый крутой модуль для бухгалтерии, но выясняется что он, в свою очередь зависит не от Dinero.js , а от decimal.js, а третий, нужный вам компонент от moneysafe.
Что тогда?
Вендоры, конечно тоже не идеальны, но, согласитесь, вероятность факапа гораздо ниже, когда главная зависимость в вашем проекте входит в стандартную библиотеку.
Как любят говорить на Хабре, инструмент надо выбирать под задачу, а не наоборот.
Да, это аналог. Вычисления скорости остаются, но можно убрать GetBytesAsync:
А вы не пробовали просто добавить в HttpClient System.Net.Http.Handlers.ProgressMessageHandler?
Зачем вообще спрашивать джуна про количество поколений CG?
а причем тут Электрон? Насколько мне известно, подписанные библиотеки поддерживает только .net'овский рантайм, да и то, используется это не очень часто.
а) это очень поверхностное суждение, потому что:
Инами словами, "дёргать read() по байтику" совсем не означает считывать по байту за раз физически.
б) вы сами-то пробовали проверять?
у меня на самсунге 850 PRO (PCI-E 3.0) c тестовым набором в 43 128 файлов объемом 2.2 ГБ:
Как видите разница в скорости небольшая и зависит от кэширования.
Зато "правильная" версия скушала 500мб RAM, а неправильная 0 (по крайней мере "на глаз" не удалось заметить выделений памяти)
А при увеличении объема правильная упала с
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceededвот вам и "ужас-ужас"
Вы правы, не скажу. Зато автор безапелляционно утверждает, что циклы — неправильно, приводит пример в разделе "Как не надо писать" с подписью про "упоротость".
По сути, он взял эффективный, но сложный алгоритм, обозвал его упоротым и переписал, подняв читабельность и пожертвовав эффективностью.
Чуть выше, RandomInternetPerson привел вариант с ленивым построчным чтением, что, ИМХО, в 80% типовых случаев будет оптимальным
ленивые последовательности в c#
И еще один неприятный сюрприз ожидает пользователей "правильной" версии, когда выяснится, что эта реализация падает с арифметическим переполнением, если в файлах, суммарно, окажется < 2,147,483,647 строчек, а sum умеет возвращать только Int.
При этом в "неправильной" версии можно использовать BigInteger
Эта реализация считывает все содержимое файлов в массив только для того, чтобы потом взять его размер, тогда как "неправильная реализация" читает посимвольно.
Вам стоит попробовать обе на папке с логами в пару гигабайт и подумать еще раз над тем, какая их них правильнее
Спасибо за маршрутчика, действительно все так :)
Но, вот все-таки, определение конкурентности и параллелизма, которые даются в статье, нуждаются в доработке.
Я бы так написал:
параллелизм:
в литературе: похожесть
в быту и академических кругах: одновременность
в геометрии: пересекаемость прямых
в программировании: вот тут поподробнее…
в общем-то, это слово уже вызывает некоторую путаницу. Я честно пытался гуглить, чтобы найти красивое определение в заслуживающем доверия источнике, но не нашел. Если вы сделаете тоже самое, то увидите, что найденные определения как-то подозрительно отличаются друг от друга. Не то чтобы сильно, но общее представление не складывается. Это корень проблемы, порождающей бесконечные споры и непонятки вокруг термина. Я запутаю его еще сильней :)
Для себя, я разделяю параллельность на машинную и алгоритмическую. Это мои собственные термины, так что можете не гуглить.
Машинная: одновременное выполнение блока машинных инструкций. Ну или «почти» одновременное (псевдопараллельность).
Алгоритмическая: никак не связана с инструкциями, процессорами и т.д. Мы просто выполняем несколько алгоритмов сразу. Это могут быть разные алгоритмы (параллелизм задач) или один и тот же, но с разными входными данными (параллелизм данных, SIMD)
Ключевой момент здесь — эти блоки инструкций или алгоритмы выполняются от начала до конца без остановки. В случае с «настоящим» параллелизмом, код выполняется на нескольких ядрах одновременно. В случае с псевдопараллелизмом, на одном, так что остановки есть, но они замаскированы и прозрачны для наблюдателя. В алгоритмическом случае мы вообще абстрагируемся от того, как что-то выполняется.
Конкурентность:
В бытовом и политическом плане: соперничество
В бизнесе и экономике: работы на одном рынке
В программировании: частный случай параллелизма
В машинном параллелизме рассматривается тема разделения времени выполнения потоков на доступные процессорные ядра: планировщик ОС выделает «кванты» времени каждому потоку по чуть-чуть, переключаясь между ними так, чтобы «никому не было обидно», как многодетная мать, которой важно, чтобы всем детям досталось ее внимание.
В алгоритмическом параллелизме мы по-прежнему абстрагированы от все этих процессоров. Вместо них рассматривается тема разделения каких-то общих ресурсов. В теории неважно, каких именно. На практике это могут быть файлы, открытые на запись, сетевые порты, периферийные устройства, которые не умеют работать параллельно или даже пользователь, которому надо показать несколько модальных окон или popup’ов, но не сразу.
В машинной конкурентности рассматриваются темы асинхронности и зеленых потоков.
В алгоритмической – примитивы синхронизации.
P.S. чтобы все запутать еще сильнее, можно упомянуть, что "просто" параллелизм и конкурентность не являются взаимоисключающими. Параллельно-конкурентное выполнение тоже возможно
Сломал мозг в попытках понять разницу.
Водитель маршрутки, который рулит, принимает оплату, говорит по телефону и щелкает семки имеет дело со многими вещами одновременно или делает много вещей одновременно?
У вас в методах GOST_Kuz_Encript и GOST_Kuz_Decript лишнее выделение памяти в переменную out_blk
С этой мышкой я прошел пусть от девятиклассика до взрослого семейного мужчины :)
За это время ее заливали лимонадом, чаем, пивом, вином, напитками покрепче, по мере взросления и в силу жизни в студ. общежитии.
В какой-то момент времени, я уверовал, что она будет работать вечно, но случился дабл-клик.
Единственное, о чем жалею, что не замерил ее точное время жизни (~ 15 лет интенсивного использования).
За это время, матовая пластмасса, под местом соприкосновения с пальцами, стерлась до гладкой блестящей поверхности (с впадинами от трения пальцами).
Мои следующие мышки прожили максимум пару лет. Сейчас использую простую двухкнопочную logitech (уже пол-года, полет нормальный)
И еще, используя копейки вместо рублей, вы снижаете диапазон допустимых значений на 2 порядка. Ошибки переполнения в отчетах за 5, 10 лет? Легко!
Стандартная библиотека, официальная библиотека от коммерческой компании и pet-project с гитхаба — все это, разные, с точки зрения надежности, библиотеки.
Выбор делается исходя из того, насколько критичный для бизнеса функционал разрабатывают.
Для финансовых организаций, валютные вычисления — это критичный функционал. Ошибки могут стоит репутации и больших денег.
При сложении/вычитании целых чисел с ошибками округления, ошибки складываются
При умножении некоторого числа с ошибкой округления на некоторый коэффициент ошибка также умножается на этот коэффициент.
Например, если у вас сумма получается умножением цены на количество, при этом цена получена с ошибкой округления до 0,5 копеек, то после умножения ее на 1000 литров (считаем цену за бензин, например) ошибка округления в сумме может достичь 50 рублей.
проблема не в том, чтобы собрать, а том, чтобы вообще не иметь таких проблем
В DineroJs 78 файлов и 9 в папке src.
И добавлять их надо будет в каждый проект этой несчастной организации.
DineroJs использует import/export, не забываем, что NodeJS поддерживает модули экспериментально.
Так что нужно будет это собирать.
У вас старая версия Babel или вообщем его нет. что тогда?
И еще тесты тоже нужно будет добавлять.
И еще 29 зависимостей добавить в devDependencies.
Ok. Будете использовать Dinero.js , а там баг. Что тогда? Извольте заплатить за приватный репозиторий NPM, делать форк, переустанавливать пакеты в куче компонентов и поддерживать это все.
Искать альтернативы NPM?
Или может просить девушку из Франции, которая поддерживает этот проект, пофиксить баг и зависеть от ее настроение и занятости?
Что будет, если Евросоюз придумает новую валюту, а мэинтейнер в декретном отпуске и ей глубого наплевать на обновление проекта?
Вы готовы доверять стороннему NPM пакету денежный процессинг в организации? А ваш начальник?
Вы хотите использовать новый крутой модуль для бухгалтерии, но выясняется что он, в свою очередь зависит не от Dinero.js , а от decimal.js, а третий, нужный вам компонент от moneysafe.
Что тогда?
Вендоры, конечно тоже не идеальны, но, согласитесь, вероятность факапа гораздо ниже, когда главная зависимость в вашем проекте входит в стандартную библиотеку.
Как любят говорить на Хабре, инструмент надо выбирать под задачу, а не наоборот.
Помимо работы с валютами и безопасности так же не хватает парсинга, форматирования и сравнения строк/дат с учетом культуры, многопоточности