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