[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: Mon, 22 Apr 2019 19:44:18 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 22.04.2019 19:28, Eli Zaretskii wrote:
Cc: address@hidden, address@hidden, address@hidden,
From: Dmitry Gutov <address@hidden>
Date: Mon, 22 Apr 2019 19:16:15 +0300

All right. Does the attached json_encode_string_ascii_test.diff look
good to you?

The size == nchars case not necessarily true just for ASCII, I think,
and the code in parse_str_as_multibyte is more complex than needed
just for ASCII.  I meant make a loop that literally checks only for
ASCII_CHAR_P, and nothing more.  I think it makes sense to see first
how much can we speed up things for pure ASCII JSONs.

OK, I'll try to do what you've described here.

In the meantime, I'd like to report that the aforementioned patch, even though too-complex and not entirely correct, provides practically all the performance improvement we get from the no-validation patch.

IOW, with my test scenario:

current master:  51s
no_validation:   21s
ascii_test:      22s

+  if (size == nchars)
+    /* Wasn't sure if the last arg should better be true here, but
+       it doesn't seem to affect the behavior or correctness, so far. */
+    return make_specified_string (data, -1, size, false);

It should make no difference for ASCII, but I think I prefer to use
'true' there, for consistency with the other cases.

I left 'false' there for testing, to make sure we hit both branches of the condition (the tests still pass).

reply via email to

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