johnzon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: JsonValue.NULL equals
Date Wed, 31 Jul 2019 18:40:48 GMT
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 <struberg@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 <struberg@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
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message