bug#31138: Native json slower than json.el

[Dmitry Gutov]

On 22.04.2019 10:03, Eli Zaretskii wrote:

> Yes.  Wasn't it 100% in your profiles?  I think it was.

Err, it probably is. The above-1% percentages sum up to 54% percent 
total. There's a long tail, though.

> > I still don't understand. I my profiling report, decode_coding_utf_8 is
> > at the top (Emacs function). Followed by malloc and produce_chars. Are
> > you saying they are not involved in decoding strings?
>
> Part (roughly half) of produce_chars is, malloc mostly isn't.

Okay, maybe some of it isn't part of code_convert_string, but libjansson 
functions themselves are way down below in my profile (though they 
probably also use malloc).

> If the percentage of the decoding was much higher, like 80% or 90%,
> say, then we would have a much better incentive to try to salvage at
> least some of that, than we have now.

As it is, we have an upper bound for optimizations: even with 
lightning-fast JSON library, performance will go up by 2x at most.

And if like you're saying in another email, we first encode the string 
before passing it to libjansson, then decode the strings in the result, 
we might be spending 70-80% of the time just doing encoding and decoding 
of strings in Emacs, if, say, encoding is twice as fast as decoding.

> > We've already had the performance numbers from before.
>
> The percentage of time taken by decoding wasn't clear to me, so I
> wanted to profile.  Mind you, I intended to do that myself, I didn't
> ask anyone to do it for me, although I'm of course grateful for your
> work on this, as it confirmed my results.

My profiling report was very different. The conclusion was, too.

> If someone has ideas how to speed up decode_coding_utf_8, please speak
> up, and let's try that.  AFAICS, it is already heavily optimized for
> the case of plain ASCII text, which is what we used in our profiling.
> If plain ASCII text is important enough, perhaps we could make this
> even faster, at the price of making non-ASCII cases slightly slower,
> by adding a function that just validates plain ASCII without producing
> a decoded string.

I'm going to have to leave that up to somebody more well-versed with C 
and Unicode.

Speaking of the specific proposal, I did something like the latter with 
json.el in the past (speeding up the ASCII-only case). It was a 
significant win.

> The original bug report found that we do unnecessary stuff like
> allocating temporary buffers and calling various hook functions -- all
> that is now gone, so we definitely have sped this up, probably
> significantly in some non-"emacs -Q" cases.

That is true. Thank you.

> FWIW, I have stream_get.part.3 in my profiles that takes almost twice
> the time as decode_coding_utf_8, and various lex_* and other functions
> also quite high on the profile, with 1.5% to 3.5%.  So it isn't like
> libjansson is tenfold faster than our code.

I don't see that in mine.