Приходил тут к нам Python, ел на завтрак JSON

[recoder]

Случилась тут у нас на работе загогулина. В процессе декомпозиции всех наших проектов на микросервисы решили мы воспользоваться шансом и поотпимизировать что можно. В частности - решили поменять JSON парсер, а то он у нас был самодельный, с поддержкой XML и хитрой валидации, но зато несовместимый ни с чем.

Пошли профайлить плюсовые JSON парсеры. Потыкали boost с его свойственными деревьями - оказалось на удивление медленно, причём и в компиляции и в рантайме. Посмотрели на Poco::JSON - более менее фурычит, хотя звёзд с неба и не хватает. Пошли смотреть что ещё бывает в современном мире C++...

А потом по приколу прогнали Python парсер на тех же тестовых данных. И тихо офигели: мерзкий питон уделал наши крутые библиотки в несколько раз. Проверили в разных аспектах - всё верно, питон быстрее плюсов. Даже для эксперимента вызвали из плюсов питоновский парсер - и он всё равно летает.

Как теперь жить с этим знанием? Переписывать всё нафик на Питоне? Таскать везде с собой кусок питона? И самый главный вопрос - как вообще такое могло получиться?!

Comments

[bash-i-buzuk.livejournal.com]

Наворочено не значит быстро :)
А GSON не смотрели? или он только на java?

[sprocket1.livejournal.com]

Он не мог как-то дополнительные вычислительные ресурсы задействовать? Многопоточность, например?

[sply.livejournal.com]

Если вы не завязаны на посторонних клиентов, то для микросервисов может оказаться удобнее MessagePack (http://msgpack.org) - можно сказать, бинарный аналог JSON. Списки, хэши поддерживает. То есть хоть бинарно, но не такая жестко как в старом RCP.

[zubian.livejournal.com]

flex & bison пробовали использовать?

[recoder]

Чёрт его знает. Но раз вызов питоновского кода из однопоточной программы на C++ показывает сходные результаты - я склонен считать что нет.

[recoder]

Увы, выбор протокола лежит за пределами моей юрисдикции. Взяли JSON + расширенную JSON Schema, и всё - никаких тебе MessagePack, ни ProtocolBuffers, ни CapnProto.

[juan-gandhi.livejournal.com]

Тут два вопроса:
- а как это?
- а какая разница, все равно ж на проводах время теряется?

[recoder]

Как на первый вопрос ответить я не совсем понимаю. Если это про методику измерения - то тестировал я так: прочитать из файла двухметровый JSON адекватной структуры, а потом в цикле на N итераций произвести разбор этой строки и быстренько пробежаться по результирующей структуре. Замеры времени делаются через /usr/bin/time

Разница существенна по трём причинам:
1) иногда ходят большие объёмы данных и хочется их побыстрее обрабатывать
2) для межсервисного обмена "время проводов" уже не покрывает время разбора
3) менеджмент хочет цифр

[recoder]

GSON на моём горизонте не появлялся, так что наверное чисто жаванский. А на жаву у меня и к бОльшей части конторы - аллергия.

[recoder]

А это как?

Мы пробовали на основе JSON Schema генерить SAX-парсеры, и это было довольно быстро, но уж очень муторно.

[zubian.livejournal.com]

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

[juan-gandhi.livejournal.com]

Два мега, нехило. Тогда да.

[jdevelop.livejournal.com]

а потом окажется, что жабий парсер уделает в несколько раз петоний ;)

[mpak666.livejournal.com]

прикольно жеж!
надо вывалить на суд общественности бенчмарки и исходники, авось и объяснения нашлись бы?!

[vtimonin.livejournal.com]

https://github.com/miloyip/nativejson-benchmark

Не знаю, как оно там относительно питона, но скорее всего RapidJSON быстрее будет.

[recoder]

Даже если так - жабу так легко не прицепить к плюсовому коду.

[recoder]

json-test.py

import json
with open('test-2.json') as f:
    d = f.read()

for n in range(0, 25):
    j = json.loads(d)

    for i in j['items']:
        v = int(i['data'][3][3])

[recoder]

json-test.Poco.cc

#include <iostream>
#include <fstream>
#include <string>
#include "Poco/JSON/JSON.h"
#include "Poco/JSON/Parser.h"
#include "Poco/JSON/Handler.h"
#include "Poco/JSON/Object.h"
#include "Poco/Dynamic/Var.h"
#include "handler.hh"

const char* JSON_FILE = "test-2.json";

using namespace std;
using namespace Poco;
using namespace Poco::JSON;
using namespace Poco::Dynamic;

void parse_file(const std::string& buffer)
{
    Parser parser;
    Var result = parser.parse(buffer);

    DynamicStruct data = *(result.extract<Object::Ptr>());
    Var items = data["items"];

    for(auto item = items.begin(); item != items.end(); ++item)
    {
        int v = (*item)["data"][3][3].convert<int>();
    }
}

int main(void)
{
    ifstream ifs(JSON_FILE);
    std::string buffer((std::istreambuf_iterator<char>(ifs)), std::istreambuf_iterator<char>());

    for (int j = 0; j < TIMES; ++j)
        parse_file(buffer);
}

[proxfessor.livejournal.com]

Вот даже кто-то уже попробовал: https://gist.github.com/justjkk/436828. Замечательная идея, между прочим.

[proxfessor.livejournal.com]

На ту же тему: читал на днях таблицу из 73000 строк и 55 колонок Питоном (pandas.readcsv) и R (readcsv). Питон прочитал а 7 раз быстрее. Крутое земноводное!

[http://users.livejournal.com/_winnie/]

Если питонячий, python-only уделывает C++ - значит, в C++ какой-то ахтунг (лишние malloc, memcpy, неявные O(N^2) и тп).


Вообще вот : http://lionet.livejournal.com/118853.html

[sleepy-drago.livejournal.com]

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

[zubian.livejournal.com]

отлично, вот даже готовый есть по сути, хотя там его сделать вообще не проблема - JSON вообще идеальный пример для реализации.

[the-drmad.livejournal.com]

flex и bison это не совсем классика, это современные кликухи для lex и yacc - а вот это, действительно, классика. Может, Recoder их под этими именами знает. Впрочем, насколько я понимаю, они там своими JSON парсерами немножко другие задачи решают.