Смысл есть от любых сравнений. Если сравнивать скорость конкатенации строк, то можно узнать, что в Java она медленная. А перфоманс языка надо уже на более сложных алгоритмах смотреть, но там каждый тест должен эксперт по конкретному языку писать, а не так, как это обычно бывает в интернете )))
Обычно при сравнении производительности просто пишут эквивалентный код на разных языках, цели написать его оптимально при этом нет, скорее наоборот. Поэтому StringBuilder применять в данной случае нельзя, т.к. автор поставил задачу замерить именно скорость "ада и содомии по созданию строк".
А то Вы такими темпами второй тест редуцируете до строчки count = 1000000 и так далее.
В общем, сравнения должны быть честными, вне зависимости от того, что сравнивается.
Попробуйте поставить -t равным кол-ву ядер на сервере, и плавно снижать -c, пока не влезет.
Главное, время выполнения оставьте, а то ваш вариант теста в течении 300 миллисекунд вообще не отражает реальность.
P.S. И wrk не с сервера запускайте, а с локального компа.
1000 запросов в 1000 потоков через ab в качестве нагрузочного тестирования? Вы серьёзно?
Запустите нормальный нагрузочный тест, что-нибудь типа: wrk -t 4 -c 100 -d30s --timeout 2000 http://127.0.0.1:8080
Ну, в следующий раз задействую… Пока методом научного тыка я запомнил главных злодеев (которые слабенький комп могут превратить в неюзабельный кусок железа): BITS, Windows Defender, SuperFetch, Windows Update, Windows Search.
Я виндой уже давно не пользуюсь, это друзья просят помочь периодически. Одну тормозящую в текущий момент службу им отключишь, так через пару дней уже что-то другое снова диск убивать начинает. В общем, ппц какой-то.
Вообще, в 10-й винде нормальный мониторинг ресурсов из коробки, но не всегда показывает конкретную службу, бывает просто System пишет и всё.
По-моему самый "забавный" нюанс Win 10 — это 100% нагрузка на диск, причём это может быть и защитник Windows или какая-нибудь фоновая интеллектуальная служба передачи или ещё какая-нибудь ересь. Не понимаю, как MS смогла так накосячить с системными службами. Интересно, есть где-нибудь полный список того, что надо отключить, чтобы винда оставила диск в покое?
O, да! Web Forms — это был гораздо более крутой изврат… Я помню фееричный анонс UpdatePanel (для тех, кто не в теме, это такой компонент на форму внутри которого автоматически AJAX типа работает) от MS-евангелиста, вот это был реальный треш и угар.
Так я и не имел в виду, что будут какие-то действительно полезные или масштабные доработки. Это скорее затыкание дыр в абстракции "асинхронный код, похожий на синхронный", которая дырява by design.
В C# 7 — "Generalized async return types", в каком-нибудь C# 8 ещё с out-параметрами накостылят или ещё что-нибудь. В принципе, о том и речь, что асинхронный код, похожий на синхронный, будет всегда плохим решением, потому что по факту он несинхронный. И аргумент, что те, кто хорошо понимает что происходит за сценой, не испытывают проблем — не работает. Потому что вся эта декорация делается не для них, а для тех, кто ещё толком не понимает… типа "не задумывайся, что код больше не синхронный, просто добавь воды async/await".
Программисты C# уже давно пишут асинхронный код с использованием async/await и не испытывают никаких проблем с граблями.
С чего Вы так решили? Ещё как испытывают и часть из этих проблем даже официально признана и решается последующими релизами C# 6, C# 7, etc.
В принципе, тут невозможно сделать недырявую абстракцию, т.к. код по факту асинхронный и попытки это замаскировать, прикинувшись, что он как бы такой же как синхронный, ни к чему хорошему не ведут. Просто чем дальше, тем более изощрёнее будут грабли.
Мне кажется, имелось в виду, что явное в данном случае лучше неявного. И если писать асинхронный код, делая вид, что он синхронный, то рано или поздно начнётся танец по граблям.
что для кастомера бага, для разработчиков может быть фичей
Вот с этим я категорически не согласен. Когда у пользователя что-то не работает или работает не так, как ожидается, то это баг, реже enhancement или usability problem, но не фича.
Фича — это когда добавляется функциональная возможность, которой раньше вообще не было (с точки зрения пользователя), а не улучшение работы существующих возможностей.
Смысл есть от любых сравнений. Если сравнивать скорость конкатенации строк, то можно узнать, что в Java она медленная. А перфоманс языка надо уже на более сложных алгоритмах смотреть, но там каждый тест должен эксперт по конкретному языку писать, а не так, как это обычно бывает в интернете )))
Обычно при сравнении производительности просто пишут эквивалентный код на разных языках, цели написать его оптимально при этом нет, скорее наоборот. Поэтому StringBuilder применять в данной случае нельзя, т.к. автор поставил задачу замерить именно скорость "ада и содомии по созданию строк".
А то Вы такими темпами второй тест редуцируете до строчки
count = 1000000и так далее.В общем, сравнения должны быть честными, вне зависимости от того, что сравнивается.
Попробуйте поставить -t равным кол-ву ядер на сервере, и плавно снижать -c, пока не влезет.
Главное, время выполнения оставьте, а то ваш вариант теста в течении 300 миллисекунд вообще не отражает реальность.
P.S. И wrk не с сервера запускайте, а с локального компа.
1000 запросов в 1000 потоков через ab в качестве нагрузочного тестирования? Вы серьёзно?
Запустите нормальный нагрузочный тест, что-нибудь типа:
wrk -t 4 -c 100 -d30s --timeout 2000 http://127.0.0.1:8080Ну, в следующий раз задействую… Пока методом научного тыка я запомнил главных злодеев (которые слабенький комп могут превратить в неюзабельный кусок железа): BITS, Windows Defender, SuperFetch, Windows Update, Windows Search.
Я виндой уже давно не пользуюсь, это друзья просят помочь периодически. Одну тормозящую в текущий момент службу им отключишь, так через пару дней уже что-то другое снова диск убивать начинает. В общем, ппц какой-то.
Вообще, в 10-й винде нормальный мониторинг ресурсов из коробки, но не всегда показывает конкретную службу, бывает просто System пишет и всё.
По-моему самый "забавный" нюанс Win 10 — это 100% нагрузка на диск, причём это может быть и защитник Windows или какая-нибудь фоновая интеллектуальная служба передачи или ещё какая-нибудь ересь. Не понимаю, как MS смогла так накосячить с системными службами. Интересно, есть где-нибудь полный список того, что надо отключить, чтобы винда оставила диск в покое?
Там как раз однопоточная вставка и сразу проблемы с race condition уходят как класс. Или Вы имеете в виду детали реализации виртуальной машины?
O, да! Web Forms — это был гораздо более крутой изврат… Я помню фееричный анонс UpdatePanel (для тех, кто не в теме, это такой компонент на форму внутри которого автоматически AJAX типа работает) от MS-евангелиста, вот это был реальный треш и угар.
Довод так себе… Их, в принципе, регулярно ломают, даже bounty-программы соответствующие есть.
Это не синонимы. Впрочем, concurrency — это конкурентность, а не конкуренция.
Так я и не имел в виду, что будут какие-то действительно полезные или масштабные доработки. Это скорее затыкание дыр в абстракции "асинхронный код, похожий на синхронный", которая дырява by design.
Сахар сахару рознь… Хороший сахар делает явное ещё более явным, плохой — явное делает неявным.
В C# 7 — "Generalized async return types", в каком-нибудь C# 8 ещё с out-параметрами накостылят или ещё что-нибудь. В принципе, о том и речь, что асинхронный код, похожий на синхронный, будет всегда плохим решением, потому что по факту он несинхронный. И аргумент, что те, кто хорошо понимает что происходит за сценой, не испытывают проблем — не работает. Потому что вся эта декорация делается не для них, а для тех, кто ещё толком не понимает… типа "не задумывайся, что код больше не синхронный, просто добавь
водыasync/await".С чего Вы так решили? Ещё как испытывают и часть из этих проблем даже официально признана и решается последующими релизами C# 6, C# 7, etc.
В принципе, тут невозможно сделать недырявую абстракцию, т.к. код по факту асинхронный и попытки это замаскировать, прикинувшись, что он как бы такой же как синхронный, ни к чему хорошему не ведут. Просто чем дальше, тем более изощрёнее будут грабли.
Мне кажется, имелось в виду, что явное в данном случае лучше неявного. И если писать асинхронный код, делая вид, что он синхронный, то рано или поздно начнётся танец по граблям.
И он, в принципе, оказался прав :-)
Но хуже даже не забывчивость, а то, что бумага всё стерпит. Но это уже из Цицерона..
А его и не обязательно как-то специально учитывать… судя по примерам lany, у тех, кто сортирует баги в JetBrains, мнение просто совпадает с моим :-)
Вот с этим я категорически не согласен. Когда у пользователя что-то не работает или работает не так, как ожидается, то это баг, реже enhancement или usability problem, но не фича.
Фича — это когда добавляется функциональная возможность, которой раньше вообще не было (с точки зрения пользователя), а не улучшение работы существующих возможностей.
Не означает конечно, но если этого не делать пару месяцев, то трекер превратится в заброшенную помойку, если вашим продуктом реально пользуются люди.