Все знают, что их обгоняет С, а С в свою очередь в два раза обгоняет Java.

А ассемблер их не обгоняет, потому что компиляторы умнее человека.

это к тому, что подобные бенчмарки должны проводиться незаангажированными

Это ведь ты, правда? Скажи что ты один из них!?

Это ведь ты, правда? Скажи что ты один из них!?

Нет, иначе я бы уже выкатил свои бенчмарки.

Везде подстава))

А человек с компилятором умнее обоих.

А компилятор с компилятором все равно умнее.

и что это значит и для кого?

о JSON::XS «скромно» забыли

А что ты предлагаешь?

Где dev-libs/json-c?

Ого, быстро. На самом деле отличный результат даже с учетом того, что это еще немного work in progress. Для полноты картины, обсуждение на оф. форуме языка: http://forum.dlang.org/thread/20151014090114.60780ad6@marco-toshiba?page=1

Код парсера: https://github.com/mleise/fast

xml

Зачем нужен JSON, когда есть INI?

Json удобно гонять по сети через WebSocket.В ini удобно сохранять конфигурацию на диск. Разные задачи.

Так... Вот с этим я уже наигрался, спасибо...

Вообще ini умеет во вложенность. А вот со списками да, печалька.

В Qt есть класс QSettings - он умеет массивы. Ini файл будет выглядеть:

[prefix]
1\key=110
2\key=90
3\key=400
size=3

Rust

Изволь померить для serde (https://github.com/serde-rs/serde).

ВЫ еще yaml вспомните

бенчмарк мерит не json-парсинг, а время отработки программ и интерпретаторов со след. логикой:

• открыть файл
• прочитать json
• суммировать значения из json-структуры

..

Ок, а подвох?

Ок, а подвох?

Удваиваю вопрос. Не верю, что возможно написать новую YOBA-реализацию какой-то в меру тривиальной вещи. Либо стандарт не полностью поддерживается, либо на каких-нибудь сочетаниях специальных символов начинает жестоко тормозить, если не падать, либо выхлоп у разных парсеров разный.

YAML rocks!

ВЫ еще yaml вспомните

Кто тут вспомнил YAML? Отличный язык разметки.

так написали уже Парсер JSON, написанный на D, стал самым быстрым парсером JSON в мире (комментарий)
на мой взгляд 1) и 2) нисколько не компрометируют реализацию, насчет 3) и 4) ничего сказать не могу, код не смотрел

Ну там активная работа со строками, её можно делать крайне наивно. Да и simd тоже прибавляет каких-то попугаев.

simd в D часть языка, если что
http://dlang.org/simd.html

обгоняя парсер на Python в более чем 6 раз по памяти и в 14 раз по скорости

Так все пользуются ujson же!

что за странное сравнение, в котором есть Ruby YAJL, который является биндингом к сишному YAJL, но нет самого YAJL? O_O

т.е. оно может и не повлияло бы, но всё равно странно так сравнивать...

Парсер JSON написанный на D стал самым быстрым парсером JSON в мире

okay

это D никак не поможет

Посмотрел ради интереса реализации бенчмарков на Go и Scala. В Go открываем файл и парсим в потоковом режиме, в Scala весь файл загружается в строку, а потом уже эта строка парсится.

Посмотрите на структуру JSON преобразованную в структуру Tcl: http://wiki.tcl.tk/40053

Да это же просто чудо!

Ехал public через void

Как вы _этим_ пользуетесь? Это же АД.

JSON-парсер на D

Он не только стал самым быстрым, но и самым ненужным!

// Calculate SSE word boundary before 'str'
// SSE aligned pointer <= 'str.ptr'.
Что из этого можно сделать на Го?

А что из этого будет работать на ARM и MIPS?

Ехал public через void

Как вы _этим_ пользуетесь? Это же АД.

Этот ад

а) довольно удобен при чтении чужих больших исходников. Чем меньше всяких неявных умолчаний тем легче разбираться.

б) вопрос привычки. Да и вообще у ява-платформы достаточно плюсов, чтобы терпеть ее дубовый синтаксис. А можно еще scala/kotlin/ceylon взять.

Жаварасты сами код не пишут, его генерирует IDE. Если это дело у них отобрать, то писаться софт будет с черепашьей скоростью.

Развитые IDE появились относительно недавно. До этого писали в емаксах и прочих блокнотах. И ничего, уделывали и С++ и всё остальное.

Тесты не валидны. С++ версия тестов использует убого написаный файловый ввод/вывод. Новость ниочем.

Это довольно сомнительно. Емаксы и прочие блокноты от IDE отличаются функционалом в меньшей степени, нежели в большей. Не всякий блокнот, но их немало таких с хорошим потенциалом.

И вот если посадить действительно за какой-нибудь кастрированный блокнот вроде nano, то скорость разработки, я гарантирую это, упадёт. Потому что язык очень многословный и ничего ты с этим не сделаешь.

Про уделывание крестов и прочих - опять же, смотря в чём.

Авторы пакетного менеджера dub за каким-то чертом json в нем заменили даже не на ini, а на богом забитый негуглимый формат sdl.

Фигасе, я только что узнал об этом.

А его кто-то реально использует? По-моему, все пакеты как пользовались, так и пользуются dub.json (который, правда, как известно, даже не совсем json, а невалидный-json-с-поддержкой-висячих-запятых). Это что, кто-то собрался депрекейтить? Или можно не обращать внимания?

Нужно добавить в новость:
Shortcomings:
- Rejects numbers with exponents of huge magnitude (>=10^28)
- Only works on Posix x86/amd64 systems
- No write capabilities
- Data size limited by available contiguous virtual memory

Это довольно сомнительно.

Что именно довольно сомнительно? Java вышла в 1995 году. Первый вменяемый эклипс в 2004 году. Половину своей истории для Java не было вменяемой IDE.

И вот если посадить действительно за какой-нибудь кастрированный блокнот вроде nano, то скорость разработки, я гарантирую это, упадёт.

Время набора текста это дай бог 10% от общего времени разработки. А то и 1-2%. Если время набора текста увеличится в 2 раза (пессимистичный сценарий), то время разработки увеличится на 10%.

Упадёт комфортность разработки. Повысится число багов. Это да. Но так в любом языке. Удобные инструменты повышают качество жизни и качество кода.

Потому что язык очень многословный и ничего ты с этим не сделаешь.

C++ не менее многословный. А то и более. Ничего, пишут в блокнотах как-то.

Про уделывание крестов и прочих - опять же, смотря в чём.

В удобстве разработки, качестве конечного результата.

сделал парсер JSON на D самым быстрым парсером в мире, обгоняя парсер на Python в более чем 6 раз по памяти и в 14 раз по скорости.

Парсер на D обогнал парсер на Python. Ну это великое достижение. Жду отчета об обгоне парсера на lua, javascript, etc.

Скачал, собрал, запустил что смог...

Javascript Node
0.49962461411279646
0.5000679585097806
0.5003248037503812
2.32s, 909.7Mb
Ruby
0.49962461411279646
0.5000679585097806
0.5003248037503812
8.18s, 2093.7Mb
D
0.49962461
0.50006796
0.50032480
8.81s, 1416.5Mb

Либо парсит он его в нечто отличное от традиционного понимания.

вложенность на пару-тройку уровней.

level_0_sublevel_0_key_0 = value

Чем это хуже иерархии json?

нисколько не компрометируют реализацию

Компрометирует в том плане, что это не «самый быстрый парсер на D», а быстрый парсер на С который вшит в D. То есть реализация не использует никакие фичи D, по этому портировать его на С не составит труда, многие части даже простым копипастом.

Вот пример кода оттуда:

char* dst = cast(char*) memcpy(buffer ? buffer : malloc(str.length + 1), str.ptr, str.length);

Сходу можно подумать что это С.

Это аналогично самому быстрому парсеру на Python, который тупо вызывает С код, но смотрите какой Python быстрый и другие языки не нужны.

и еще два:

Python
0.499624614113
0.50006795851
0.50032480375
8.06s, 1410.1Mb
C++ Boost
0.49962461
0.50006796
0.50032480
11.23s, 2860.4Mb

Парсер JSON, написанный на D, стал самым быстрым парсером JSON в мире (комментарий)

Это даже слишком человечно.

Развитые IDE появились относительно недавно. До этого писали в емаксах и прочих блокнотах. И ничего, уделывали и С++ и всё остальное.

Жаль, что в природе не встречаются приложения на яве, которые не тормозят и не срут исключениями в лог с последующими падениями.

scala/kotlin/ceylon

gracias

Прогать мышкой? Это всё объясняет.

И не выжирают память на 100+ тредах.