bug#31138: Native json slower than json.el

[Dmitry Gutov <dgutov@yandex.ru>]

On 22.04.2019 20:12, Eli Zaretskii wrote:

> Like this:
> 
> diff --git a/src/json.c b/src/json.c
> index 16500bc..48aeccf 100644
> --- a/src/json.c
> +++ b/src/json.c
> @@ -225,8 +225,12 @@ json_has_suffix (const char *string, const char *suffix)
>   static Lisp_Object
>   json_make_string (const char *data, ptrdiff_t size)
>   {
> -  return code_convert_string (make_specified_string (data, -1, size, false),
> -                              Qutf_8_unix, Qt, false, true, true);
> +  struct coding_system coding;
> +  setup_coding_system (Qutf_8_unix, &coding);
> +  coding.mode |= CODING_MODE_LAST_BLOCK;
> +  coding.source = data;
> +  decode_coding_object (&coding, Qnil, 0, 0, size, size, Qt);
> +  return coding.dst_object;
>   }
>   
>   /* Create a multibyte Lisp string from the NUL-terminated UTF-8
> 
> 
> How does this fare in your benchmarks?

It's not nothing, but it doesn't remotely compare to avoiding the 
decoder entirely. Here's a table with different patches and 
corresponding timings. Your last patch is at the end.

I have to admit that somehow my previous measurement of the "none" 
performance was off, maybe due to cold disk cache, maybe due to busy CPU 
or whatever. So it's not 51s but faster.

| patch                        | runtime (s) |
|------------------------------+-------------|
| none (current master)        |        36.8 |
| no validation                |        21.7 |
| ascii_only check             |        21.8 |
| using coding_system directly |        34.5 |

I have also tried your suggested scenario (where the file is read only 
once), but it made the "none" case faster by 2 seconds. So I decided 
against repeating all tests with it.