bug#31138: Native json slower than json.el

[Dmitry Gutov]

On 23.04.2019 17:58, Eli Zaretskii wrote:

> > Doing that for buffer text as well might be helpful.
>
> In what use cases would this be helpful?  Most cases of decoding text
> in a buffer happen when we read text from files, where we already have
> an internal optimization for plain ASCII files.

HTTP request response buffers? They can be as large as several 
megabytes, as we have established in this discussion.

> We could perhaps try
> a similar optimization for UTF-8 instead of just ASCII.

I think so.

> Use cases where we read without decoding and then decode buffer
> contents "by hand" are relatively rare, certainly when the stuff to
> decode is so large that the performance gains will be tangible.

Maybe be. We could try and benchmark, though.

> > So that's why I mentioned decode-coding-string (though
> > code_convert_string would be a better choice; or decode_coding_object?),
> > as opposed to creating a new specialized function.
>
> code_convert_string also handles encoding, though.

That's just one more comparison. We could also do that in 
decode_coding_object instead, but I'm not sure about the overhead of the 
intervening code.

> > What I can understand from our testing, this kind of change improves
> > performance for all kinds of strings when the source encoding is
> > utf_8_unix. Even for large ones (despite you expecting otherwise).
>
> I tested 10K strings, and the advantage there already becomes
> relatively small.  10K characters may be a lot for strings, but it
> isn't for buffers.

That's probably true. I have tried a similar shortcut, removing the 
code_convert_string call in json_encode (which is called once from 
json-parse-string), and that did not measurably affect its performance.

But it did increase the performance of json-serialize, by more than 2x, 
on the same test data I've been using.

Like 3.8s to 1.6s for 10 iterations.

Can we do something like that? Removing conversion altogether is 
probably not an option, but even using Fstring_as_unibyte instead lead 
to a significant improvement (2,43s with this approach).

diff --git a/src/json.c b/src/json.c
index 7d6d531427..01682473ca 100644
--- a/src/json.c
+++ b/src/json.c
@@ -266,7 +266,7 @@ json_encode (Lisp_Object string)
 {
   /* FIXME: Raise an error if STRING is not a scalar value
      sequence.  */
-  return code_convert_string (string, Qutf_8_unix, Qt, true, true, true);
+  return string;
 }

 static AVOID