v0.7.1

A performance release with no change to what jz reads or writes. jz run COMMAND and --parser NAME read only the definitions that answer to the name, so a short conversion with a named parser takes about a tenth of the time it did, and csv files and tables with many columns are read in about half the time with less memory. The documentation site has a page comparing jz with jc and jo, with the benchmark script that produced its figures.

Added

• A comparison with jc 1.25.7 and jo 1.9 on the documentation site and in the README: what each reads and builds, where each is the better choice, what jsonize does not do, and timings and peak memory measured on all cores and on one core with scripts/compare_bench.sh, including the cases where jc or jo is faster.

Changed

• jz run COMMAND and --parser NAME read only the built-in definitions that answer to the name, not all 737. On a short df -h report pinned to one core, jz --parser df takes about 5 ms instead of 46 ms and jz run df -h about 6 ms instead of 47 ms. Detecting the format from the text still reads every definition. With a registry of your own, every definition is read as before.
• Reading a csv allocates a quarter of what it did and takes about half the time: every record was read through a new 4 KB buffer, and one buffer now serves the whole input.
• A table whose rows hold more than eight columns, such as ps aux or top, no longer builds a map for each row, and a process time such as 4:50 is added up in whole seconds unless it has a fraction. On 100,000 rows of ps aux jz takes about half the time and a third less memory.