Comments 40
А сами тесты производительности есть в Гите? и почему в самих результатах нет Protobuf?
да конечно, там жэ указаны соурсы тестов
смотрите тут:
github.com/aumcode/nfx/blob/master/Source/Testing/Manual/WinFormsTest/SerializerForm2.cs
это именно "ручные кликабельные" тесты для винды и линукса
несколко сотен интеграйшон тестов там нет т.к. они в другой закрытой базе.
унит тест на Слим:
github.com/aumcode/nfx/tree/master/Source/Testing/NUnit/NFX.NUnit/Serialization
протобуф эти тести в принципе не проидет — там цикли объектов
смотрите тут:
github.com/aumcode/nfx/blob/master/Source/Testing/Manual/WinFormsTest/SerializerForm2.cs
это именно "ручные кликабельные" тесты для винды и линукса
несколко сотен интеграйшон тестов там нет т.к. они в другой закрытой базе.
унит тест на Слим:
github.com/aumcode/nfx/tree/master/Source/Testing/NUnit/NFX.NUnit/Serialization
протобуф эти тести в принципе не проидет — там цикли объектов
Ок, но меня интересует применимость для моего случая — у меня много линейных больших DTO, которые я сериализую протобафом. Вот и вопрос — имеет ли смысл пробовать ваш сериализатор для моего случая.
сделайте тест. думаю что скорость Слим будет такой-же как протобуф для линейнои структуры или может Слим будет процентов на 10 медленнее т.к. мы же делаем намного больше (например разруливаем ссылки),
ОДНАКО ЕСЛИ вы правилно поставите TypeRegistry и батчинг моде в Слим можно будет обрабатывать быстрее — мне надо знать во что (в поток, в фаил, сокет, етц..)
идут ваши данные и как вы их читаете назад (по 1 по батчу етц.)
ОДНАКО ЕСЛИ вы правилно поставите TypeRegistry и батчинг моде в Слим можно будет обрабатывать быстрее — мне надо знать во что (в поток, в фаил, сокет, етц..)
идут ваши данные и как вы их читаете назад (по 1 по батчу етц.)
А как насчет MsgPack? Или Avro?
это сериализатори «general purpose» — они не могут сериализуроват сушествуюшие CLR типы прозрачно.
попробуите перенести Dictionary<string, Dictionary<FID, Node>> на другую машину.
сложные цикличесние графы вообще в JSON-подобные форматы автоматически не пишутся.
Вы можете вручную разложит это в линеиный список — но это надо писать, а слим делает это за вас
Авро мы смотрели пару лет назад, и остались разочарованы качеством и багами. Извините, детали тестов не сохранились — врать не буду
попробуите перенести Dictionary<string, Dictionary<FID, Node>> на другую машину.
сложные цикличесние графы вообще в JSON-подобные форматы автоматически не пишутся.
Вы можете вручную разложит это в линеиный список — но это надо писать, а слим делает это за вас
Авро мы смотрели пару лет назад, и остались разочарованы качеством и багами. Извините, детали тестов не сохранились — врать не буду
сложные цикличесние графы вообще в JSON-подобные форматы автоматически не пишутся.JSON.NET умеет без особых проблем, надо только включить в конфиге.
знаем, но это медленно.
Ранше они не умели делать классы которые сами себя пишут через [OnSer/Deser***]/ISerializable.
Даже если это заработало — все равно медленно будет ибо ни JSON ни BSON не могут делать кастом битмаппинг для специалных типов.
Кстати классный баг — Dicitonary<string, object>(CultureInvariantStringComparer) компарер рушил CLR — с unmanaged exception from mscrolib из-за нрепрабилного вызова [OnDeserialized...]
Ранше они не умели делать классы которые сами себя пишут через [OnSer/Deser***]/ISerializable.
Даже если это заработало — все равно медленно будет ибо ни JSON ни BSON не могут делать кастом битмаппинг для специалных типов.
Кстати классный баг — Dicitonary<string, object>(CultureInvariantStringComparer) компарер рушил CLR — с unmanaged exception from mscrolib из-за нрепрабилного вызова [OnDeserialized...]
Взгляд со стороны: под JVM уже много лет различные библиотеко-писатели упражняются в написании самых быстрых, самых компактных и самых удобных сериализаций, посмотрите хотя бы это: github.com/eishay/jvm-serializers/wiki, хотя и там много разработок не упомянуто.
Вопрос: CLR — непаханое поле в этом плане?
Вопрос: CLR — непаханое поле в этом плане?
В.НЕТ очен много тоже всего есть.
Скажу вам честно — написать хороший сериализатор, и главное отладить его — ето сотни часов работы.
Слим сериализатор может побить многие сериализаторы только по 1й причине.
У нас UNISTACK- т.е. все наше, а значит мы можем делать «special treatment» для всяких системных структурок
которие исползуются ДРУГИМИ узлами нашей болшой сыстемы.
Например, знает ли MsgPack ili Avro ili Thrift ili ProtoBuf про какие-то специалные крючки для репликации данных в ДБ — конечно нет, и не должен,
но тогда заплатите за скорость.
Скажу вам честно — написать хороший сериализатор, и главное отладить его — ето сотни часов работы.
Слим сериализатор может побить многие сериализаторы только по 1й причине.
У нас UNISTACK- т.е. все наше, а значит мы можем делать «special treatment» для всяких системных структурок
которие исползуются ДРУГИМИ узлами нашей болшой сыстемы.
Например, знает ли MsgPack ili Avro ili Thrift ili ProtoBuf про какие-то специалные крючки для репликации данных в ДБ — конечно нет, и не должен,
но тогда заплатите за скорость.
Вот здесь есть сравнение производительности наиболее известных сериализаторов в .NET: theburningmonk.com/2015/04/binary-and-json-benchmarks-updated-2
Кстати, если верить результатам, то некоторые JSON сериализаторы уже почти догнали protobuf, а в некоторых ситуациях могут и обгонять (по-крайней мере по тестам самих авторов).
Кстати, если верить результатам, то некоторые JSON сериализаторы уже почти догнали protobuf, а в некоторых ситуациях могут и обгонять (по-крайней мере по тестам самих авторов).
Кстати, Степанов вещает много похожего на UNISTACK, например: youtu.be/QmuMHtbO4ug и youtu.be/Dx1MZh6KYCk Но скорее как о далекой мечте, и когда-то в СССР был банк алгоритмов, и на западе в 60х-70х много говорили о сертифицированных, много раз проверенных алгоритмах (по которым собирается статистика и глобальная степень перееиспользования для которых должна быть такой огромной, что в них уже не может быть ошибок). Вообще идея того, что должен быть один язык, одна библиотека, один подход, одна архитектура, один фюрер летает в воздухе с самого основания программирования, как дисциплины. Только в последние 10 лет началась эта отрава в умах, что «нельзя решить все задачи одним языком» или «для каждого случая хорош свой инструмент». Разве не очевидно, что эти принципы не противоречат друг-другу, только тогда есть свои инструменты для каждого случая, когда в основе всего этого разнообразия инструментов лежит один фундамент. Языки и инструменты должны быть построены в нечто вроде дерева, где на каждом более высоком слое происходит разветвление (специализация), а на каждом более низком — обобщение (унификация). В конечном счете, в основе всего лежит математика, как самый абстрактный способ моделирования и физика, как база для создания моделирующих машин. А сейчас в программировании такая ситуация, что все разнообразие порождено не необходимостью специализации, а волюнтаризмом или жадностью. Волюнтаризмом т.е. произволом разработчиков, мол захотелось — я и сделал. И жадностью гигантов ИТ индустрии — которым нужны свои, непохожие ни на что, инструменты и языки только для порождения искусственной несовместимости. Неспецифическая конкуренция, когда специфики нет, а различие придумано искусственно — загадило нам все программирование. Но как, как двигаться к юнистеку? Как двигаться к одним стандартам? Как двигаться к обобщению, если все плывут в другую сторону? У меня только один ответ — отходить в сторону и делать все самому, да, это первое время порождает +1 к хаосу и фрагментации инструментов и языков, но стоит кому-то начать, и сделать что-то безапелляционно хорошо, как вот с Линуксом, с nginx, с V8 и c другим открытым ПО получилось, то за ним потянутся.
100% согласен.
вы прямо «расскусили» то что мы делаем уже несколько лет с НФХ.
вообще очень хорошо, что до МС дошло наконец, что сидеть со своим CLR-закрытым кодом
как казначей на сундуке в замке кощея — себе дороже. они осознали что кащей смертен — и открыли
ядро. эти потуги шли в Микрософте уже пару лет.
одно можно сказать, или даже ДОКАЗАТЬ — чем меньше кода и он проще — тем лучше.
современный software stack поломан. Как может быть простой MVC для веба у Микрософта — сотни тысяч или даже миллионы
строчек?
Смотрим сюда, это весь MVC, где код? И он делает всё что нужно (routing, action filtering, security, param binding, complex data JSON/multipart etc..). Где код? Его нет! < 1500 loc
github.com/aumcode/nfx/tree/master/Source/NFX.Wave/MVC
это я как раз про модели математические мира. Они есть (как формы Платона) хотим мы того или нет — сама суть
структуры мира. Вопрос только в интерпритации — а индикатор правилного пути — простота и легкость
аум!
вы прямо «расскусили» то что мы делаем уже несколько лет с НФХ.
вообще очень хорошо, что до МС дошло наконец, что сидеть со своим CLR-закрытым кодом
как казначей на сундуке в замке кощея — себе дороже. они осознали что кащей смертен — и открыли
ядро. эти потуги шли в Микрософте уже пару лет.
одно можно сказать, или даже ДОКАЗАТЬ — чем меньше кода и он проще — тем лучше.
современный software stack поломан. Как может быть простой MVC для веба у Микрософта — сотни тысяч или даже миллионы
строчек?
Смотрим сюда, это весь MVC, где код? И он делает всё что нужно (routing, action filtering, security, param binding, complex data JSON/multipart etc..). Где код? Его нет! < 1500 loc
github.com/aumcode/nfx/tree/master/Source/NFX.Wave/MVC
это я как раз про модели математические мира. Они есть (как формы Платона) хотим мы того или нет — сама суть
структуры мира. Вопрос только в интерпритации — а индикатор правилного пути — простота и легкость
аум!
github.com/aumcode/nfx/tree/master/Source/NFX.Wave/MVC
Не вижу работу с асинхронностью. Не вижу кеширования метаданных. Перфоманс скорее всего там не живет.
Работы с middleware типа OWIN не замечено. Свои биндинги параметров не написать. Возможности настроить и использовать свой Service Locator/Container нет. Зато полно каких то костылей. Кому нужен такой недоделаный велосипед (вопрос риторический)?
Это беглый осмотр. Если провести сравнение по полному фичелисту, то будет еще более грусно.
Не вижу работу с асинхронностью. Не вижу кеширования метаданных. Перфоманс скорее всего там не живет.
Работы с middleware типа OWIN не замечено. Свои биндинги параметров не написать. Возможности настроить и использовать свой Service Locator/Container нет. Зато полно каких то костылей. Кому нужен такой недоделаный велосипед (вопрос риторический)?
Это беглый осмотр. Если провести сравнение по полному фичелисту, то будет еще более грусно.
по пунктам которые вы затронули:
асинхронность:
github.com/aumcode/nfx/blob/master/Source/NFX.Wave/WorkContext.cs#L233
+hybrid injectable dispatcher
кэш метаданных:
github.com/aumcode/nfx/blob/master/Source/NFX.Wave/Handlers/TypeLookupUtils.cs
github.com/aumcode/nfx/blob/master/Source/NFX.Wave/MVC/Reflection.cs
скорость: запросто 100 000 запросов в секунду отвечая JSON на запрос с параметрами, и это все с паттерн матчингом и штук 6 фильтров. МС МВЦ даже близко так не может
берите здесь и убедитесь сами:
github.com/aumcode/nfx/blob/master/Source/Testing/Manual/WaveTestSite/Controllers/Tester.cs#L75-90
OWIN? а зачем он нам? У нас все своё (UNISTACK методология), такжэ мы не поддерживаем ЯваБеанс и еще около 50К стандартов :)
параметры:
github.com/aumcode/nfx/blob/master/Source/NFX.Wave/Handlers/MVCHandler.cs#L171-L230
github.com/aumcode/nfx/blob/master/Source/NFX.Wave/MVC/Attributes.cs#L172-182
Локатор/Контаинер? А это что?
github.com/aumcode/nfx/blob/master/Source/Testing/Manual/WaveTestSite/Program.cs
github.com/aumcode/nfx/blob/master/Source/Testing/Manual/WaveTestSite/WaveTestSite.laconf#L136-423
локатор:
github.com/aumcode/nfx/blob/master/Source/Testing/Manual/WaveTestSite/WaveTestSite.laconf#L254
этот «велосипед» имеет намного болше возможностеи чем Ms MVC, проше и быстрее на порядок.
На этом написано реално несколко сайтов которые держат устойчиво десятки тысяч запросов/секунду
асинхронность:
github.com/aumcode/nfx/blob/master/Source/NFX.Wave/WorkContext.cs#L233
+hybrid injectable dispatcher
кэш метаданных:
github.com/aumcode/nfx/blob/master/Source/NFX.Wave/Handlers/TypeLookupUtils.cs
github.com/aumcode/nfx/blob/master/Source/NFX.Wave/MVC/Reflection.cs
скорость: запросто 100 000 запросов в секунду отвечая JSON на запрос с параметрами, и это все с паттерн матчингом и штук 6 фильтров. МС МВЦ даже близко так не может
берите здесь и убедитесь сами:
github.com/aumcode/nfx/blob/master/Source/Testing/Manual/WaveTestSite/Controllers/Tester.cs#L75-90
OWIN? а зачем он нам? У нас все своё (UNISTACK методология), такжэ мы не поддерживаем ЯваБеанс и еще около 50К стандартов :)
параметры:
github.com/aumcode/nfx/blob/master/Source/NFX.Wave/Handlers/MVCHandler.cs#L171-L230
github.com/aumcode/nfx/blob/master/Source/NFX.Wave/MVC/Attributes.cs#L172-182
Локатор/Контаинер? А это что?
github.com/aumcode/nfx/blob/master/Source/Testing/Manual/WaveTestSite/Program.cs
github.com/aumcode/nfx/blob/master/Source/Testing/Manual/WaveTestSite/WaveTestSite.laconf#L136-423
локатор:
github.com/aumcode/nfx/blob/master/Source/Testing/Manual/WaveTestSite/WaveTestSite.laconf#L254
этот «велосипед» имеет намного болше возможностеи чем Ms MVC, проше и быстрее на порядок.
На этом написано реално несколко сайтов которые держат устойчиво десятки тысяч запросов/секунду
асинхронность: github.com/aumcode/nfx/blob/master/Source/NFX.Wave/WorkContext.cs#L233
Сожалею, но на семафорах и тредах это не асинхронность, это синхронизация.
кэш метаданных:
Проглядел. В коде очень сложно проследить за зависимостями.
>скорость: запросто 100 000
Пока ваш фреймворк не появится хотя бы тут, ваши заявления не имеют значения. Вы можете тестировать на железе которое может выдать и 200к запросов на другом фреймворке.
параметры:
Не очень удобно. Но да, биндинги.
Локатор/Контаинер? >А это что?
Я хочу свой же. Там написано. Я хочу к примеру Ninject или Autofac, и логи от log4net.
>На этом написано реално несколко сайтов
А на ASP.NET MVC не «несколько сайтов» :)
Сожалею, но на семафорах и тредах это не асинхронность, это синхронизация.
кэш метаданных:
Проглядел. В коде очень сложно проследить за зависимостями.
>скорость: запросто 100 000
Пока ваш фреймворк не появится хотя бы тут, ваши заявления не имеют значения. Вы можете тестировать на железе которое может выдать и 200к запросов на другом фреймворке.
параметры:
Не очень удобно. Но да, биндинги.
Локатор/Контаинер? >А это что?
Я хочу свой же. Там написано. Я хочу к примеру Ninject или Autofac, и логи от log4net.
>На этом написано реално несколко сайтов
А на ASP.NET MVC не «несколько сайтов» :)
нигде и не появится, нам не нужен ПР.
у нас цель зацепить талантливых русских ребят себе в комманду — что мы и сделали меньше чем за 5 дней от публикации кода в гит хуб.
интересно обозревать динамику Хабра — болшинство комментариев вообще не в тему, флайм и высер.
то что вы «хотите» авто-фак или нинджект — вы бы сначала почитали статью
и материалы про UNISTACK:
github.com/aumcode/nfx/wiki/NFX-Unistack-Overview
ну а аффто-фак нам не очен хочется применять
удачи
у нас цель зацепить талантливых русских ребят себе в комманду — что мы и сделали меньше чем за 5 дней от публикации кода в гит хуб.
интересно обозревать динамику Хабра — болшинство комментариев вообще не в тему, флайм и высер.
то что вы «хотите» авто-фак или нинджект — вы бы сначала почитали статью
и материалы про UNISTACK:
github.com/aumcode/nfx/wiki/NFX-Unistack-Overview
ну а аффто-фак нам не очен хочется применять
удачи
про асинхронность — я с вами 100% согласен, но вы невмнимательно посмотрели в код.
WAVE — это гибридный сервер, в нем не такая модель обработки как в ИИС или АСП.НЕТ
хотя может быть и такой. То что я вам показал — ето режим работы когда HTTP Work,
github.com/aumcode/nfx/blob/master/Source/NFX.Wave/WorkContext.cs#L233
, никто болше не владеет. Здесь можно делат намного более гибкие модели процессинга,
например 1 сред на 10,000 клиентов доставляет им чат. У нас нет всех этих «костылеи»
для реактивного программирования. Все делается намного проше за счет того что все
исползует уже написанниы код и МОЖЕТ положится на него всегда, например на App.Log или
на Апп.Glue. Т.е. — ви можете пропросить не убивать WorkContext- и манаджать его сами именно тем
паттерном который нужен для решения задачи, что намного гибче чем ASYNC AWAIT на уровне конкретных актионс
WAVE — это гибридный сервер, в нем не такая модель обработки как в ИИС или АСП.НЕТ
хотя может быть и такой. То что я вам показал — ето режим работы когда HTTP Work,
github.com/aumcode/nfx/blob/master/Source/NFX.Wave/WorkContext.cs#L233
, никто болше не владеет. Здесь можно делат намного более гибкие модели процессинга,
например 1 сред на 10,000 клиентов доставляет им чат. У нас нет всех этих «костылеи»
для реактивного программирования. Все делается намного проше за счет того что все
исползует уже написанниы код и МОЖЕТ положится на него всегда, например на App.Log или
на Апп.Glue. Т.е. — ви можете пропросить не убивать WorkContext- и манаджать его сами именно тем
паттерном который нужен для решения задачи, что намного гибче чем ASYNC AWAIT на уровне конкретных актионс
Чем больше я вас читаю, тем больше у меня создается ощущение, что вы все сделали/знаете, как сделать, лучше, чем MS. Я правильно вас понял?
а, что для вас микрософт и статуя свободы есть абсолутный эталон?
а как же может тогда быть такое что например Node, Rubi и Puthon, Erlang etc… живут и процветают?
каждый тоол хорош для того для кого он хорош.
задача михрософта — разводить сотни тысяч девелоперов на «самое новое» — перекладывая из пустого в порожнее,
и держать цену акций, которые все ребята умные давно продали (вклучая самого Била)
мы ничего не продаём в области ИТ технологий.
я написал — наша задача была знакомство с талантливыми ребятами именно из СССР.
если вам интересно, есть по -делу вопросы, пишите!
а как же может тогда быть такое что например Node, Rubi и Puthon, Erlang etc… живут и процветают?
каждый тоол хорош для того для кого он хорош.
задача михрософта — разводить сотни тысяч девелоперов на «самое новое» — перекладывая из пустого в порожнее,
и держать цену акций, которые все ребята умные давно продали (вклучая самого Била)
мы ничего не продаём в области ИТ технологий.
я написал — наша задача была знакомство с талантливыми ребятами именно из СССР.
если вам интересно, есть по -делу вопросы, пишите!
Нет, для меня Microsoft — это производитель определенного количества технологий и фреймворков. В том числе, и тех, которыми пользуетесь вы. Но в предлагаемом вами решении вы последовательно отвергаете многое (если не все) из того, что они предлагают — сериализацию, TPL, более высокоуровневые решения (я уже не говорю про архитектурные решения, навроде того же DI).
Вот мне и интересно: вы это делаете потому, что считаете, что все эти вещи реализовали лучше?
Вот мне и интересно: вы это делаете потому, что считаете, что все эти вещи реализовали лучше?
Есть вещи — как музыка Баха — вне времени — классика.
CLR — написан очень хорошо, и меня никогда не подводил — работает предсказуемо и позволяет решать 99.8% задач.
C# — очен хорошо продуманная, и универсальная вешь
90% построенного вокруг етого — просто ужасно — и это потому что МС не можeт все зачеркнуть легаси.
Например вообше XML/SOAP — это мода 90х годов. Сеичас REST, а суть тажа. А через 10 лет будет RPC- и все будут кричать что толко RPC!, then again ZML-2, XAML, FARMl, YAML etc…
А *nix концепции не менялис 30 лет. До сиц пор ест grep, awk, bash, C, C++,…
Будет ли Microsoft ASP.NET через 5 лет? — (популярен) — уже начался исход, и АСП 5 — не имеет ничего обшего с тем что было раньше, — just the name «ASP»
вот есть все-таки классный софт: Линух Кернел, ОРАКЛ, Делфи (до версии 7 в свое время), МонгоДБ, его не так много…
а есть тонны мусора — это 10000 билиотек которие делают все тоже самое 150 тысяч раз. — например логгинг в текстовый фаил
в итоге очен сложно все ето охватит и поддерживать.
наша библиотека тоже мусор для вас, и для 99%.НЕТ community Но для 0.01% ето именно то что надо.
CLR — написан очень хорошо, и меня никогда не подводил — работает предсказуемо и позволяет решать 99.8% задач.
C# — очен хорошо продуманная, и универсальная вешь
90% построенного вокруг етого — просто ужасно — и это потому что МС не можeт все зачеркнуть легаси.
Например вообше XML/SOAP — это мода 90х годов. Сеичас REST, а суть тажа. А через 10 лет будет RPC- и все будут кричать что толко RPC!, then again ZML-2, XAML, FARMl, YAML etc…
А *nix концепции не менялис 30 лет. До сиц пор ест grep, awk, bash, C, C++,…
Будет ли Microsoft ASP.NET через 5 лет? — (популярен) — уже начался исход, и АСП 5 — не имеет ничего обшего с тем что было раньше, — just the name «ASP»
вот есть все-таки классный софт: Линух Кернел, ОРАКЛ, Делфи (до версии 7 в свое время), МонгоДБ, его не так много…
а есть тонны мусора — это 10000 билиотек которие делают все тоже самое 150 тысяч раз. — например логгинг в текстовый фаил
в итоге очен сложно все ето охватит и поддерживать.
наша библиотека тоже мусор для вас, и для 99%.НЕТ community Но для 0.01% ето именно то что надо.
Спасибо, что вы так и не ответили на мой вопрос.
вы можте задат конкретно вопрос?
с радостью отвечу очен детално вклучая код и референсы.
почемы мы обходим 90%.НЕТ стака?
отвечаю: потому что нам удалось создать совсем другого уровня систему для распределенного обслужйвания
клиентов, где объемы данних и транзакций были таковыми, что МС технологии вообше не предназначены для этого.
была разработана методология UNISTACK — в ней мы работаем болше 20 лет и толко сеичас мы решили поделится своим опытом дабы привлеч мозги — поэтому пыбликация на Хабре
с радостью отвечу очен детално вклучая код и референсы.
почемы мы обходим 90%.НЕТ стака?
отвечаю: потому что нам удалось создать совсем другого уровня систему для распределенного обслужйвания
клиентов, где объемы данних и транзакций были таковыми, что МС технологии вообше не предназначены для этого.
была разработана методология UNISTACK — в ней мы работаем болше 20 лет и толко сеичас мы решили поделится своим опытом дабы привлеч мозги — поэтому пыбликация на Хабре
Ну то есть, я правильно вас понимаю: вы обходите 90% .net, потому что ваша реализация той же функциональности (в нужном вам объеме, конечно) — лучше?
А зачем что-то домысливать в нечетких терминах лучше/хуже, если можно просто сделать эксперимент и измерить.
Я не очень понимаю, как померять вещи вроде «намного более гибкие модели процессинга» (vs TPL), выигрыш/потери от отказа от
async/await, преимущества от фиксированного DI и так далее.Можно померить комплексную производительность систем, решающих одинаковые задачи, созданные на базе разных технологий. И еще очень важно померить производительность программистов, использующих эти тулы. Если можно задачу решить быстрее, то преимущество очевидно, если поддерживать систему дешевле, то этот качественный показатель уже можно подсчитать количественно. Могут быть конечно такие случаи, когда преобразование качественных показателей в количественные само по себе очень ресурсоемко и мы не можем сделать такой эксперимент. В этом случае можно использовать метод экспертных оценок. И уже в самом страшном случае мы можем признать, что вопрос выходит за пределы человеческого познания, но до таких вопросов еще добраться нужно.
Можно. Все можно. Но чтобы это «померять» имело какое-то адекватное значение, должны быть выполнены n условий (например, должна быть одинаковая квалификация программистов). Добротное такое исследование в долгосрочной перспективе.
Но мне-то интересно другое. Когда человек, читающий мой код, задает мне вопрос «почему ты здесь используешь не стандартное X, а твое Y», у меня обычно есть ответ — «мое Y лучше» или «X не умеет вот так» или «когда писали, X не было» или «я про X не знал» или еще сколько-то разных. И мне интересен как раз такой субъективный ответ автора.
Но мне-то интересно другое. Когда человек, читающий мой код, задает мне вопрос «почему ты здесь используешь не стандартное X, а твое Y», у меня обычно есть ответ — «мое Y лучше» или «X не умеет вот так» или «когда писали, X не было» или «я про X не знал» или еще сколько-то разных. И мне интересен как раз такой субъективный ответ автора.
Одинаковая квалификация программистов не обязательна, это условие сложно реализовать, проще провести серию измерений и иметь репрезентативную выборку, чтобы разница в квалификации была сглажена. Конечно есть интуиция специалиста, основанная на опыте, и очевидно, что если человек что-то делает, то он верит в то, что делает, а то бы не делал и не писал бы нам эту статью. Я Вам скажу, что за свои 20 лет профессионального опыта программирования я неоднократно наблюдал, как один человек мог сделать лучше, чем сотни профессионалов и серьезные ИТ гиганты. Лишь потому, что этим гигантам вовсе не нужно делать хорошо, им нужно зарабатывать деньги и обеспечивать регулярность продаж, захватывать первенство на рынке, завоевывать лояльность потребителя любыми способами, вплоть до очевидного зомбирования. Для решения этих задач любой продукт должен иметь целый ряд заранее продуманных изъянов и в концепциях и в реализациях. Отсюда нарочная несовместимость, чрезмерная сложность, закрытость кода, чтобы даже научиться это делать было невозможно без вложения больших денег и сертификации.
В виде пакета не думали сделать?
нет.
UNISTACK — это отсутствие каких-либо пакетов по определению
github.com/aumcode/nfx/wiki/NFX-Unistack-Overview
UNISTACK — это отсутствие каких-либо пакетов по определению
github.com/aumcode/nfx/wiki/NFX-Unistack-Overview
Проблема в том, что protobuf и thrift кроссплатформенные. Этими пакетами можно обмениваться с любыми другими платформами на любых поддерживаемых языках.
А с вашим увы и ах.
А с вашим увы и ах.
Удивлен тестом Thrift, не указано ничего из конфигурации трифта, о том какой стек тестировался и т.п., а без этого судить о скорости в рамках мы в 20 раз быстрее как минимум не серьезно.
Почему нет исходников тестов трифта?
Сериализация в thrift реализована очень близко к «очень быстрому» proto, с оговоркой на возможность использования различных форматов данных.
Почему нет исходников тестов трифта?
Сериализация в thrift реализована очень близко к «очень быстрому» proto, с оговоркой на возможность использования различных форматов данных.
И да качеством кода трифта для C# я был разочарован :)
blog.aumcode.com/2015/03/apache-thrift-vs-nfxglue-benchmark.html
соурса на тест Трифт в НФХ нет, — не могу забивать свой код
если вам очень надо — я могу попросить своего партнёра отыскать исходник этого теста.
пишите в скайп: i...t..ad..a.p.t.er(точки удалить)
соурса на тест Трифт в НФХ нет, — не могу забивать свой код
если вам очень надо — я могу попросить своего партнёра отыскать исходник этого теста.
пишите в скайп: i...t..ad..a.p.t.er(точки удалить)
Хорошая работа, но ту ли проблему решаем. Protobuf, Thrift и тот же WCF дают явное определение интерфейсов, програмист должен задуматься что должно выдавтся за границы системы/сервиса, а что нет.
А автоматические генераторы, сериализаторы размывают физические границы системы что для ленивого програмиста/архитектора создаёт соблазн сделать сильно связаную систему где на каждый чих мы переганяэм мегабайты через сеть.
А автоматические генераторы, сериализаторы размывают физические границы системы что для ленивого програмиста/архитектора создаёт соблазн сделать сильно связаную систему где на каждый чих мы переганяэм мегабайты через сеть.
именно ту.
Слим писался для NFX.Glue — организации супер процессов где адресное пространство «размазано» между сотнями машин.
Интерфейс лубого объекта уже есть — это сам объект который уже продекларирован. Glue нужен именно для «склеивания» таких
инстансов а Слим это имеено двигатель Glue
github.com/aumcode/nfx/tree/master/Source/NFX/Glue
пример:
github.com/aumcode/nfx/blob/master/Source/NFX/Instrumentation/Telemetry/ITelemetryReceiver.cs
Слим писался для NFX.Glue — организации супер процессов где адресное пространство «размазано» между сотнями машин.
Интерфейс лубого объекта уже есть — это сам объект который уже продекларирован. Glue нужен именно для «склеивания» таких
инстансов а Слим это имеено двигатель Glue
github.com/aumcode/nfx/tree/master/Source/NFX/Glue
пример:
github.com/aumcode/nfx/blob/master/Source/NFX/Instrumentation/Telemetry/ITelemetryReceiver.cs
BTW где сравнение с главным хранилищем (качественных и оттестированных) велосипедов ServiceStack?
Sign up to leave a comment.
NFX — Ультраэффективная Бинарная Сериализация в CLR