[Top][All Lists]

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

bug#31138: Native json slower than json.el

From: Alex Gramiak
Subject: bug#31138: Native json slower than json.el
Date: Mon, 22 Apr 2019 21:06:26 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Dmitry Gutov <address@hidden> writes:

> On 22.04.2019 22:52, Alex Gramiak wrote:
>> The following might work, though I'm not
>> sure how applicable this is now to the jansson library:
> Peformance patches are 200% better when they come together with benchmark
> results.

Right, I should have explained: I meant that since AFAIU the size of
json_int_t is usually going to be the same size as EMACS_INT, the same
code will usually be generated for json.c. It might bring a very slight
benefit to other parts of Emacs, but not worth fussing over.

I tried making a couple patches in other areas to json.c that I hoped
would slightly improve performance, which I'll include here for
posterity. The first one uses json_dumpb over json_dumps, but from what
I can tell using it is either slower or just within error. The second
uses the *_nocheck functions where applicable, but the results seemed to
be quite similar. I suppose this means that jansson's utf-8 checking is

Benchmark for the first patch:
  (setq v ["\nasdфыв\u001f\u007ffgh\t"])
  (progn (garbage-collect)
         (benchmark-run-compiled 100000
           (json-serialize v)))

Results for the first patch: 1.1050s applied vs. 1.1078s without.

Attachment: json-dumpb.diff
Description: json_dumpb

Benchmark for the second patch:

  (setq v (with-current-buffer (find-file-noselect
            (vector (buffer-substring-no-properties (point-min)

    (progn (garbage-collect)
           (benchmark-run-compiled 1000
             (json-serialize v)))
Results for the second patch: 0.7815s applied vs. 0.7962s without.

Attachment: json_*_nocheck.diff
Description: nocheck

reply via email to

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