jackson vs json simple для разбора потока

У меня есть библиотека json на github https://github.com/jillesvangurp/jsonj

Эта библиотека имеет синтаксический анализатор на основе JSON simple, который использует класс обработчика для выполнения всей работы по созданию экземпляров JsonObject, JsonArray и JsonPrimitive, которые есть в моей библиотеке.

Я видел, как люди публикуют различные тесты, предполагающие, что синтаксический анализатор Джексона примерно так же хорош, как и в плане производительности, и что JSON simple-один из более медленных вариантов. Итак, чтобы посмотреть, смогу ли я повышая производительность, я создал альтернативный парсер, который использует API потоковой передачи jackson и вызывает тот же обработчик, который я использовал для исходного парсера. Это прекрасно работает с функциональной точки зрения и было довольно простым.

Вы можете найти соответствующие классы здесь (JsonHandler, JsonParser и JsonParserNg): https://github.com/jillesvangurp/jsonj/tree/master/src/main/java/com/github/jsonj/tools

Однако я не вижу никаких улучшений в различных тестах, которые я использую. побежал.

Итак, мой вопрос: Должен ли я вообще видеть какое-либо улучшение, и если да, то почему? Мне кажется, что в потоковом режиме API, по крайней мере, обе библиотеки имеют одинаковую производительность.

Я бы очень заинтересовался опытом других людей в этом.

1 3
jackson json-simple

1 ответ:

Я написал " о надлежащем тестировании производительности обработки Java JSON" некоторое время назад, чтобы перечислить общие проблемы, которые я видел с бенчмаркингом производительности. Есть много относительно простых способов испортить сравнение. Я предполагаю, что вы не совершаете ни одной из упомянутых ошибок, но это стоит упомянуть. Особенно в части использования raw input: очень мало случаев, когда реальные данные JSON поступают в виде String -- поэтому обязательно используйте InputStream / OutputStream (или байтовые массивы).

Второй следует отметить, что если вы используете модель дерева (например, JsonObject) , вы уже добавляете много потенциально предотвратимых накладных расходов: вы создаете Map/List структуры, которые используют память 3x, что POJOs будет использовать; и медленнее работать. В этом случае фактические накладные расходы на синтаксический анализ / генерацию обычно являются миноритарным компонентом в любом случае. Иногда обработка в стиле дерева имеет смысл, и это приемлемые накладные расходы.

Поэтому, если производительность имеет большое значение, обычно либо:

  1. использует потоковое API для создания собственных объектов - не дерево в памяти, или
  2. использует привязку данных К / из POJOs. Это может быть близко к скорости (1)
Оба из которых будут быстрее, чем построение деревьев (и в некоторой степени сериализация). По какой-то причине многие разработчики почему-то предполагают, что работа с древовидными представлениями является таким же эффективным способом работы с данными, как и любой другой-это не так, и видно в таких тестах, как https://github.com/eishay/jvm-serializers

Я не видел связанный с Джексоном код по ссылке, поэтому я предполагаю, что он работает так, как ожидалось. Основные вещи, чтобы искать (представление относительно проблемы) действительно до:

  1. всегда близко JsonParser и JsonGenerator (требуется для некоторой переработки) и
  2. повторное использование JsonFactory и/или ObjectMapper экземпляров: они потокобезопасны, повторное использование некоторых компонентов (таблиц символов, сериализаторов) происходит через эти объекты.
  3. Как упоминалось ранее, всегда используйте большинство необработанных направлений ввода / вывода, если это возможно (InputStream, OutputStream).
7