bug#21616: [PATCH] Enable sorting of JSON object keys when encoding

[Simen Heggestøyl]

Hello, Dmitry.

On Mon, Nov 9, 2015 at 1:01 AM, Dmitry Gutov <dgutov@yandex.ru> wrote:

Call it json-[encode-]key-sort-predicate, maybe?

Indeed, "predicate" seems more appropriate. I'll change the name.

The unification part makes me concerned, again, from the performance standpoint. Did you do any measuring here?

I didn't before now, but as you feared, the performance became

measurably worse when encoding plists and hash-tables.

I performed some benchmarks on the same 560K JSON file as before

(http://folk.uio.no/simenheg/huge.json), with the following results:

With json-object-type set to hash-table:

  Before the patch:

  (benchmark-run 100 (json-encode huge))

       ⇒ (17.396825399 800 7.954568797999999)

  After the patch:

  (benchmark-run 100 (json-encode huge))

       ⇒ (19.338006244000002 700 9.664285849000013)

With json-object-type set to plist:

  Before the patch:

  (benchmark-run 100 (json-encode huge))

       ⇒ (15.152158676 1101 7.109026906)

  After the patch:

  (benchmark-run 100 (json-encode huge))

       ⇒ (18.122579887 777 8.46547749400001)

How about keeping the old encoding code as the default, and only do the

{hash-table, plist} → alist transform when the output is to be sorted?

That keeps new code to a minimum, and the they would need to be

transformed to an intermediate structure to be sorted anyway.

A patch implementing this suggestion is attached. Here are the same

benchmarks with the new patch applied:

With json-object-type set to hash-table:

  (benchmark-run 100 (json-encode huge))

       ⇒ (17.229601604 750 8.015517397999995)

With json-object-type set to plist:

  (benchmark-run 100 (json-encode huge))

       ⇒ (14.363185863 1101 6.992225689000007)

-- Simen

0001-Enable-sorting-of-JSON-object-keys-when-encoding.patch
Description: Text Data