Быстрее XML регрессия производительности при работе со списком? - PullRequest
Новая
       117

Быстрее XML регрессия производительности при работе со списком?

2 голосов
/ 03 мая 2020

Я оцениваю более быструю производительность XML (v 2.11.0) при разных конфигурациях («простой» objectMapper, используя Afterburner, smile и т. Д. c), и во время моих тестов производительности jmh я обнаружил некоторые странные результаты. Кажется, что производительность для десериализации списка очень и очень плохая. Вот метод, использованный для теста 

protected void testMapper(List<Persona> persone, Blackhole bh,ObjectMapper jsonMapper) throws Exception {
    String personeAsStr=jsonMapper.writeValueAsString(persone);
    bh.consume(personeAsStr);
    List<Persona> personeDeser=jsonMapper.readValue(personeAsStr,List.class);
    bh.consume(personeDeser);
}

Если вместо List я использую объект, содержащий персона, в качестве свойств, производительность будет совершенно другой.

Вот код, используемый для другого test 

protected void testMapperPersone(PersoneForBenchmark personeForBenchmark, Blackhole bh,ObjectMapper jsonMapper) throws Exception {
    String personeAsStr=jsonMapper.writeValueAsString(personeForBenchmark);
    bh.consume(personeAsStr);
    PersoneForBenchmark personeDeser=jsonMapper.readValue(personeAsStr,PersoneForBenchmark.class);
    bh.consume(personeDeser);
}

Где PersonaForBenchmark выглядит примерно так: 

public class PersoneForBenchmark {
    private Persona persona0;
    private Persona persona1;
    private Persona persona2;
    private Persona persona3;
    private Persona persona4;
    private Persona persona5;
    private Persona persona6;
    private Persona persona7;
    private Persona persona8;
    private Persona persona9;
    //plus getters and setters
}

Результаты производительности следующие:

FasterXMLPerformance.fasterXMLStandard 19,504 операций / с

FasterXMLPerformance.fasterXMLStandardPersone 10772 836 операций / с

Я пытался использовать TypeReference, объект, содержащий список, но результаты по существу совпадают. Другой аспект, который меня озадачивает, заключается в том, что пропускная способность теста (для контрольного примера списка) уменьшается после каждой итерации. Вот пример журнала jmh: ​​

 Run progress: 18,75% complete, ETA 00:16:30
 Fork: 1 of 1
 Warmup Iteration   1: 218,673 ops/s
 Warmup Iteration   2: 83,445 ops/s
 Warmup Iteration   3: 57,964 ops/s
 Warmup Iteration   4: 46,002 ops/s
 Warmup Iteration   5: 39,482 ops/s
 Warmup Iteration   6: 34,743 ops/s
 Warmup Iteration   7: 31,322 ops/s
 Warmup Iteration   8: 28,361 ops/s
 Warmup Iteration   9: 26,241 ops/s
 Warmup Iteration  10: 24,520 ops/s
Iteration   1: 23,291 ops/s
Iteration   2: 22,062 ops/s
Iteration   3: 20,236 ops/s
Iteration   4: 19,886 ops/s
Iteration   5: 19,379 ops/s

Полный набор тестов доступен здесь . Может кто-нибудь сказать мне, если я делаю что-то не так или это действительно снижение производительности?

1 Ответ

1 голос
/ 09 мая 2020

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

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

При этом я бы предложил вам подать проблему для jackson-databind github repo, с некоторой информацией из выше, и ссылками на этот вопрос. Я добавлю еще несколько предложений в чат Gitter (https://gitter.im/FasterXML/jackson-databind)

Но сразу же полезно было бы узнать, если у указанных c более старых версий не было этой проблемы. В 2.11 произошли изменения в разрешении типов (со временем он был изменен), что могло вызвать регрессию для некоторого варианта использования - мы выполняем тест производительности, но в основном с более простыми List s (List<String> et c).

...