Hello, Dmitry.
Indeed, "predicate" seems more appropriate. I'll change the name.
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