bug#31138: Native json slower than json.el

[Eli Zaretskii]

> Cc: sebastien@chapu.is, yyoncho@gmail.com, 31138@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 22 Apr 2019 01:12:49 +0300
> 
> On 21.04.2019 12:31, Eli Zaretskii wrote:
> 
> >> Eli, how did you reach that conclusion?
> > 
> > By adding the percentage of all the functions involved in decoding
> > strings.
> 
> Was the total sum of the profile 100%?

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

> > I only accounted for time used by Emacs code, i.e. 100% doesn't
> > include the library.
> 
> 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.

> > In any case, even if decoding takes 50% of the time we spend in Emacs
> > code, it is still not significant enough to justify the un-safety of
> > using a string that we didn't decode, because if that string ever
> > includes raw bytes, Emacs will surely crash.
> 
> What was the point of us doing the exercise, and me wasting time on it, 
> if you're set on not changing anything at all?

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.

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

> Given the encouragement, I really expected you to choose *some* path 
> toward improvement. Either forgoing conversion (maybe adding an 
> additional test suite, for cases you're worrying about), or doing some 
> kind of faster validation instead of full conversion (where we don't 
> allocate new strings but just check existing ones for validity), or, you 
> know, optimizing everything everywhere.

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.

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.

> Considering libjansson manages to do both JSON parsing and string 
> conversion in ~the same time make_specified_string only does string 
> conversion on the returned strings, it most likely follows that 
> make_specified_string could be made faster.

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.