You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@johnzon.apache.org by Mark Struberg <st...@yahoo.de.INVALID> on 2019/07/31 16:56:46 UTC

JsonValue.NULL equals

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


Re: JsonValue.NULL equals

Posted by Romain Manni-Bucau <rm...@gmail.com>.
It is for null, true and false but recall we had a bug due to that even if
no more sure which one.

What is slow exactly? Isnt it inlined at some point? Or do we call it too
often? (fix is different ;).

Le mer. 31 juil. 2019 à 18:57, Mark Struberg <st...@yahoo.de.invalid> a
écrit :

> 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
>
>

Re: JsonValue.NULL equals

Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <st...@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
> >
>
>

Re: JsonValue.NULL equals

Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <st...@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
>