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

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