Try the new System.Text.Json APIs

For .NET Core 3.0, we’re shipping a brand new namespace called System.Text.Json with support for a reader/writer, a document object model (DOM), and a serializer. In this blog post, I’m telling you why we built it, how it works, and how you can try it.
— https://devblogs.microsoft.com/dotnet/try-the-new-system-text-json-apis/

Здравствуйте, Qbit86, Вы писали:

Q>

Try the new System.Text.Json APIs
Q>For .NET Core 3.0, we’re shipping a brand new namespace called System.Text.Json with support for a reader/writer, a document object model (DOM), and a serializer. In this blog post, I’m telling you why we built it, how it works, and how you can try it.
Q>— https://devblogs.microsoft.com/dotnet/try-the-new-system-text-json-apis/

Ну да, переписали все на Span. Иначе странно получается, стек весь новый супероптимизированный, а JSON парсим по старинке, через копирование. Да и то что на сторонний Json.Net завязано полфреймворка — не есть гут.

new Utf8JsonWriter(stream, options)

Шёл 21 век... программисты как могли избавлялись от нудной, раздражающей "кодировки". Но не тут-то было! На те вам обухом по пальцам! Дикость... просто дикость.

JSON deserialization (input)

Newtonsoft.Json   136,435
System.Text.Json  167,861

JSON serialization (output)

Newtonsoft.Json  120,273
System.Text.Json 145,631

эээ... серьёзно? вот ради ЭТОГО вы бросили улучшать свои существующие уродливые библиотеки и бросили силы на развлекушки с JSON? (при том, что существуют минимум 4 библиотеки для подобного, включая фаворита от Newtonsoft)
Помогите мне проснуться, я вижу страшный до приятности сон, как Дуров покупает MS и даёт пендаль Наделле.

Здравствуйте, Qbit86, Вы писали:

Q>

Try the new System.Text.Json APIs

Q>For .NET Core 3.0, we’re shipping a brand new namespace called System.Text.Json with support for a reader/writer, a document object model (DOM), and a serializer. In this blog post, I’m telling you why we built it, how it works, and how you can try it.
Q>— https://devblogs.microsoft.com/dotnet/try-the-new-system-text-json-apis/

А есть понимание какие задачи можно решить новым инструментом проще, чем ранее существующими ? Я лично не так много задач решал с парсингом json, хватало обычно функционала Newtonsoft и мне не совсем очевидно на что надо обратить внимание в новой имплементации в .net core.

Здравствуйте, okon, Вы писали:

O>А есть понимание какие задачи можно решить новым инструментом проще, чем ранее существующими ?

Дело не в простоте, а в перформансе и расходе ресурсов.

Здравствуйте, Kolesiki, Вы писали:


K>эээ... серьёзно? вот ради ЭТОГО вы бросили улучшать свои существующие уродливые библиотеки и бросили силы на развлекушки с JSON? (при том, что существуют минимум 4 библиотеки для подобного, включая фаворита от Newtonsoft)
K>Помогите мне проснуться, я вижу страшный до приятности сон, как Дуров покупает MS и даёт пендаль Наделле.

Для наиболее распространенных размеров полезной нагрузки System.Text.Json предлагает увеличение пропускной способности MVC на 20% при форматировании ввода и вывода с меньшим объемом памяти.

Ну перформансе в 20% это не хилый прирост по нынешним меркам. Плюс можно посмотреть в сторону .Net Native для исключения рефлекшина https://github.com/dotnet/corert

Здравствуйте, Serginio1, Вы писали:

S> Ну перформансе в 20% это не хилый прирост по нынешним меркам. Плюс можно посмотреть в сторону .Net Native для исключения рефлекшина https://github.com/dotnet/corert

При чем тут рефлекшин, такие либы давно строят высокоэффективные экспрешины и компилят прямо во время исполнения. Оврхед только при первой сериализации.

Здравствуйте, Serginio1, Вы писали:

S> Ну перформансе в 20% это не хилый прирост по нынешним меркам.

Говорить об абстрактной "производительности" минимум дилетантство — всегда должен быть контекст.

Например, прибавка FPS в игре, где было 25, а стало 30 — это КРУТО. Потому что низкий рэйт он повышает пусть не до высот, но даёт нехватающую прибавку.
А если ты с сети получаешь объект (что уже медленно) и потом его парсишь, засовываешь в базу и т.п., вообще нет никакого смысла в выжимании процентов — в целом система будет "равномерно тормозить" без особых проблем для обработки.

Другими словами, мелкомягкие закрыли в жигулях боковые стёкла и улучшили "стремительность" на 0.0001% Глупая растрата ресурсов. И я б ещё понял, если б люди жаловались на нехватку скорости, пытались что-то переписать... но нет — все счастливы и только очень тупой манагер мелкософта, у которого ниже поясницы завёлся NIH-синдром, не спит по ночам и ёрзает — ну как же так, какой-то newtonsoft написал популярнейшую библиотеку, а мы тут бесславно сидим и хороним никому не нужный WCF! Давайте уже ещё что-нибудь ненужное напишем!

Здравствуйте, Danchik, Вы писали:

D>При чем тут рефлекшин, такие либы давно строят высокоэффективные экспрешины

Я скажу больше — там вообще всё на T4 можно затемплейтить.

Здравствуйте, Kolesiki, Вы писали:

K>Здравствуйте, Serginio1, Вы писали:

S>> Ну перформансе в 20% это не хилый прирост по нынешним меркам.

K>Говорить об абстрактной "производительности" минимум дилетантство — всегда должен быть контекст.

K>Например, прибавка FPS в игре, где было 25, а стало 30 — это КРУТО. Потому что низкий рэйт он повышает пусть не до высот, но даёт нехватающую прибавку.
K>А если ты с сети получаешь объект (что уже медленно) и потом его парсишь, засовываешь в базу и т.п., вообще нет никакого смысла в выжимании процентов — в целом система будет "равномерно тормозить" без особых проблем для обработки.

И наоборот, все складывается с кирпичиков. Тут прибавили в скорости, там оптимизнули, глядишь все забегало бодрее.

K>Другими словами, мелкомягкие закрыли в жигулях боковые стёкла и улучшили "стремительность" на 0.0001% Глупая растрата ресурсов. И я б ещё понял, если б люди жаловались на нехватку скорости, пытались что-то переписать... но нет — все счастливы и только очень тупой манагер мелкософта, у которого ниже поясницы завёлся NIH-синдром, не спит по ночам и ёрзает — ну как же так, какой-то newtonsoft написал популярнейшую библиотеку, а мы тут бесславно сидим и хороним никому не нужный WCF! Давайте уже ещё что-нибудь ненужное напишем!

Я бы на твоем месте почитал статью и разобрался почему они решили переписать. Кратко, с текущим дизайном либы без поломки обратной совместимости они ничего сделать не могли. Также иметь зависимость в ядре от Json.Net не есть гут.

Здравствуйте, Danchik, Вы писали:

D>Здравствуйте, Serginio1, Вы писали:

S>> Ну перформансе в 20% это не хилый прирост по нынешним меркам. Плюс можно посмотреть в сторону .Net Native для исключения рефлекшина https://github.com/dotnet/corert

D>При чем тут рефлекшин, такие либы давно строят высокоэффективные экспрешины и компилят прямо во время исполнения. Оврхед только при первой сериализации.
А экспрешины это, не динамическая компиляция? Если, что речь идет об .Net Native

Здравствуйте, Serginio1, Вы писали:

S> А экспрешины это, не динамическая компиляция? Если, что речь идет об .Net Native
А они там есть только без кешированичя
https://github.com/JamesNK/Newtonsoft.Json/issues/968

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, Serginio1, Вы писали:

S>> А экспрешины это, не динамическая компиляция? Если, что речь идет об .Net Native
_NN>А они там есть только без кешированичя
_NN>https://github.com/JamesNK/Newtonsoft.Json/issues/968

Угу если и есть то какое то убогое

I develop a music player app for the Windows Store and used Newtonsoft.Json for the serialization of playlists. The difference in performance between my Release build which has .Net Native enabled and my Debug build is huge. So here are my results from testing with a large playlist with 16000 songs:
Serializing with Newtonsoft.Json:
DEBUG: 0,760678 seconds
RELEASE: 7,9427199 seconds
Deserializing with Newtonsoft.Json:
DEBUG: 1,7782815 seconds
RELEASE: 10,6551608 seconds
As a comparison I tested the same playlist with ServiceStack.Text Json Serializer:
Serializing with ServiceStack.Text Json:
DEBUG: 0,9823664 seconds
RELEASE: 9.0322984 seconds
Deserializing with ServiceStack.Text Json:
DEBUG: 0,9636399 seconds
RELEASE: 1.1934371 seconds
Conclusion: Please do something about this issue because as of today Newtonsoft.Json is not usable in my app.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, _NN_, Вы писали:

_NN>>Здравствуйте, Serginio1, Вы писали:

S>>> А экспрешины это, не динамическая компиляция? Если, что речь идет об .Net Native
_NN>>А они там есть только без кешированичя
_NN>>https://github.com/JamesNK/Newtonsoft.Json/issues/968

S> Угу если и есть то какое то убогое
Разработчикам всё не угодишь.
Как забирают API (.NET Core) то жалуются, а как оставляют (.NET Native Expressions) то тоже недовольны

Ну там есть решение, использовать кеш.
Непонятно почему он не идёт с .NET Native сразу хотя бы в виде библиотеки.

Здравствуйте, _NN_, Вы писали:

_NN>Разработчикам всё не угодишь.
_NN>Как забирают API (.NET Core) то жалуются, а как оставляют (.NET Native Expressions) то тоже недовольны

_NN>Ну там есть решение, использовать кеш.
_NN>Непонятно почему он не идёт с .NET Native сразу хотя бы в виде библиотеки.

Ну речь то идет о System.Text.Json. Может оно уже оптимизировано под .NET Native
Просто этот аспект никто не учитывал

Здравствуйте, Kolesiki, Вы писали:


K>

K>new Utf8JsonWriter(stream, options)
K>

K> Шёл 21 век... программисты как могли избавлялись от нудной, раздражающей "кодировки". Но не тут-то было! На те вам обухом по пальцам! Дикость... просто дикость.

Кстати, да. Оптимизированный вариант следовало бы скрыть за общим JsonWriter. Если стоит кодировка UTF-8, то он бы сам включался бы. А вот выносить этот недо-костыль на уровень публичного API — дилетантство. Впрочем, типичное для .NET Core.

Здравствуйте, Serginio1, Вы писали:


S>

S>I develop a music player app for the Windows Store and used Newtonsoft.Json for the serialization of playlists. The difference in performance between my Release build which has .Net Native enabled and my Debug build is huge. So here are my results from testing with a large playlist with 16000 songs:

Ему бы SQLite туда завезти.

Здравствуйте, Нахлобуч, Вы писали:

S>>

S>>I develop a music player app for the Windows Store and used Newtonsoft.Json for the serialization of playlists. The difference in performance between my Release build which has .Net Native enabled and my Debug build is huge. So here are my results from testing with a large playlist with 16000 songs:

Н>Ему бы SQLite туда завезти.

Не факт что прочитать из sqlite будет быстрее чем десериализовать json