bounded lenient canonicalization

[brandonbloom]

The total ordering is pretty nice, but it has a cost: Printing larger structures is much slower. Although Fipp promises linear time & bounded space, Puget's sorting cannot. Occasionally, I print a pretty large structure with Puget/Whidbey and have a little flashback to a dark time before I wrote fipp.

Incomplete design thought: There should be an option for lenient canonicalization, which recovers the performance promises.

For all counted? collections, we could check if (> (count coll) limit) and, if so, don't sort bother that structure. A reasonable default limit would be some scalar factor (0.5 to 2 or so) of Fipp's print width, which is also used internally for bounding the measurement queue.

[greglook]

Ah, good points. When I was writing Puget as part of Vault, the main focus was on canonical printed representations so that the results hashed consistently. Now that its main use is in the REPL, it's probably reasonable to add a :sort-mode option that lets the user choose between always sort (the current default), never sort, or conditionally sort using some heuristic (perhaps configured with a :sort-limit key?)

There's already some precedent for tweaking the canonicalization with the :strict setting.

[greglook]

Took a crack at this, I think the updates in e0d3da8 should solve your issue here. I didn't want to make things too complex, so the new :sort-keys option has three possible states:

• true will cause all map and set collections to be sorted (this is the default).
• An integer will cause collections up to that size to be sorted, larger ones will be iterated as-is.
• false will not sort any collection keys

[brandonbloom]

This works great for me. Thanks!