[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31138: Native json slower than json.el

From: Dmitry Gutov
Subject: bug#31138: Native json slower than json.el
Date: Tue, 23 Apr 2019 00:00:29 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]