То есть автор пропозала потратил время, ответил вам развёрнуто что, где и как, а вы представляете это "мне автор ответил, что он лучше знает". Я верно вас понял?
Без тестов на .net core выводы делать так себе. Потому что .net framework переведён в maintenance мод и в .net core была куча оптимизаций (в рантайме, джите и BCL), не все из которых портированы обратно в полный фреймворк.
Да, иногда наш остальной код оптимизирован. А иногда метод, в котором вы оптимизируете, вызывается миллионы или миллиарды раз в час. Ну и там получается нормально.
По поводу первого доклада — ну там всё туманно, потому что официальной реализации пайплайнов поверх сокетов в дотнете нет, надо будет брать неофициальную.
Если мы берём пайплайны, то надо адаптировать msgpack библиотеки к работе над ReadOnlySequence и к чтению одного MsgPack токена из нескольких буферов.
Это всё займёт не один день, поэтому я особо и не распространяюсь. Я уже пообещал как-то релиз в июле, а потом куча изменений в жизни заставили отложить этот релиз.
В мире продаж, где есть слово "скидка", процесс тривиален и всем известен?
AFAIK, сервис тот же самый, морда лица (приложение) — другое.
Про Хаскель не скажу, а на F# делают это всё. Плюс, реактивная модель неплохо ложится на иммутабельность и прочую функциональщину.
Ну, шарповый пример на Linq в одном месте с причитаниями, что замедление в 10 раз недопустимо — это всегда смешно :)
То есть автор пропозала потратил время, ответил вам развёрнуто что, где и как, а вы представляете это "мне автор ответил, что он лучше знает". Я верно вас понял?
Некоторые люди говорят, что химия, физика и математика — не творчество. Зачем слушать необразованных людей? ;)
А. Ну то есть ровно столько же (плюс-минус), сколько и за нормальные языки. На которые тоже есть спрос у бизнеса. Странный плюс, который у всех плюс.
Хорошо — это сколько?
Без тестов на .net core выводы делать так себе. Потому что .net framework переведён в maintenance мод и в .net core была куча оптимизаций (в рантайме, джите и BCL), не все из которых портированы обратно в полный фреймворк.
Спасибо за тесты.
Это странно. Запустите ещё пару раз. В релизе. Из командной строки. И не используйте при этом компьютер.
Без разницы, см. бенчмарк
Ну так нет. Есть бенчмарк, который показывает, что деоптимизации нет.
Нет никакой деоптимизации.
Вы удивитесь, но влияет и очень сильно.
Это зависит от коллекции.
Это всего лишь сахар для:
Так что всё зависит от реализации MoveNext.
Если тип collection — массив и компилятору это точно известно, то там будет просто проход по индексу.
Выше бенчмарк, запустите его на моно.
Это не так.
Во-первых, это приветствуется прятать во всякие методы и классы отдельные.
Во-вторых, есть ref/Span, которые полностью безопасны.
Да, иногда наш остальной код оптимизирован. А иногда метод, в котором вы оптимизируете, вызывается миллионы или миллиарды раз в час. Ну и там получается нормально.
Для подобных вещей есть давно BenchmarkDotNet. Вот, например, вариант кода и результаты.
Как можно увидеть — никакого влияния на производительность вынос Length не имеет.
По поводу первого доклада — ну там всё туманно, потому что официальной реализации пайплайнов поверх сокетов в дотнете нет, надо будет брать неофициальную.
Если мы берём пайплайны, то надо адаптировать msgpack библиотеки к работе над ReadOnlySequence и к чтению одного MsgPack токена из нескольких буферов.
Это всё займёт не один день, поэтому я особо и не распространяюсь. Я уже пообещал как-то релиз в июле, а потом куча изменений в жизни заставили отложить этот релиз.