> 7. Including additional cases for exact values to avoid extra function calls to "parseString(&s.br)" or "s.parseNumber()". I can see how you might choose som

> 7. Including additional cases for exact values to avoid extra function calls to "parseString(&s.br)" or "s.parseNumber()". I can see how you might choose some numbers to optimize for (1..10 for example) - but strings? You could of course do a frequency analysis of the test data - but would that help in general, beyond just cheating on the benchmark? I guess you could try for "key" and "value", and maybe "id"? Possibly adding "email" and "name"? Also from tfa regarding numbers: > Scanner.parseNumber is slow because it visits its input twice; once at the scanner and a second time when it is converted to a float. I did an experiment and the first parse can be faster if we just look to find the termination of the number without validation, canada.json went from 650mb/s to 820mb/sec.