If valuetype is enough +1000 (also for booleans probably?), will avoid the regression we had which was about implementing custom JsonValue with asym equals from memory (kind of inline value/anonym class).
Le mer. 31 juil. 2019 à 19:45, Mark Struberg <strub...@yahoo.de.invalid> a écrit : > This would have quite some impact! > > 2.5 Million Polo->json->pojo roundtrips took > > Johnzon-1.1.12 110 seconds > After my first improvements 103 seconds > After getting rid of most java.lang.reflect.Array.* operations: 85 seconds > After replacing JsonValue.NULL.equals with == (and same for > JsonValue.TRUE, etc) 57 seconds. > That's quite some gain I'd say ;) > > It all relies on whether we can rely on == is sufficient. > > Just got Romains answer: > > What is slow exactly? Isnt it inlined at some point? Or do we > > call it too often? (fix is different ;). > > It's used pretty often in our code. Doesn't look like we do too much. Just > used very often. > > The performance gain is imo enough to investigate it further. > At some code parts we already have a JsonValue. Means we could also > replace > JsonValue.NULL.equals(jsonValue) with > ValueType.NULL == jsonValue.getValueType() > which would be perfectly portable again. > > LieGrue, > strub > > > > Am 31.07.2019 um 18:56 schrieb Mark Struberg <strub...@yahoo.de.INVALID > >: > > > > hi folks! > > > > We have quite some JsonValue.NULL.equals(...) in our code. > > Seems this part is slow according to YourKit. > > > > Wouldn't it be perfectly enough to use JsonValue.NULL == ? > > > > LieGrue, > > strub > > > >
