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 19:00:13 +0300
> 
> On 22.04.2019 18:50, Eli Zaretskii wrote:
> > (You should have used
> > insert-file-contents-literally instead.)

(And, to answer your question: insert-file-contents doesn't use
code_convert_string, it decodes text as it being read, directly in the
buffer's gap.)

> I wonder if there's a counterpart for that for HTTP responses returned 
> by url-retrieve.

There is, if we need: bind coding-system-for-read to 'no-conversion'.

> > And I don't think we will be
> > able to speed up the general-purpose decoding routines: no one said
> > the original file is encoded in UTF-8.
> 
> We could speed up certain important cases, like where the bytes are 
> identical between the source and the destination.

Not sure what you mean by "source" and "destination".

In any case, coding.c is already heavily optimized, certainly in the
UTF-8 case.  You and others are welcome to profile the code looking
for opportunities to optimize even more, but I'd be surprised if you
find something significant.  In particular, UTF-8 decoding validates
as part of the decoding loop, and is already optimized for ASCII, so
it will be interesting to see what kind of gains we could have in
json_make_string by testing for ASCII up front.