Optimize position search in error path

[purplesyringa]

Translating index into a line/column pair takes considerable time. Notably, the JSON benchmark modified to run on malformed data spends around 50% of the CPU time generating the error object.

While it is generally assumed that the cold path is quite slow, such a drastic pessimization may be unexpected, especially when a faster implementation exists.

Using vectorized routines provided by the memchr crate increases performance of the failure path by 2x on average.

Old implementation:

			DOM         STRUCT
data/canada.json        122 MB/s    168 MB/s
data/citm_catalog.json  135 MB/s    195 MB/s
data/twitter.json       142 MB/s    226 MB/s

New implementation:

			DOM         STRUCT
data/canada.json        216 MB/s    376 MB/s
data/citm_catalog.json  238 MB/s    736 MB/s
data/twitter.json       210 MB/s    492 MB/s

While this introduces a new dependency, memchr is much faster to compile than serde, so compile time does not increase significantly. Additionally, memchr provides a more efficient SWAR-based implementation of both the memchr and count routines even without std, providing benefits for embedded uses as well.

[purplesyringa]

For easier comparison, here are the results of the benchmark for the success path on the same machine:

                        DOM         STRUCT
data/canada.json        283 MB/s    416 MB/s
data/citm_catalog.json  429 MB/s    864 MB/s
data/twitter.json       275 MB/s    541 MB/s

[dtolnay]

Thank you!

I wonder where else memchr can be profitably applied. Maybe this loop:

json/src/read.rs

Lines 546 to 548 in 40dd7f5

	while self.index < self.slice.len() && !ESCAPE[self.slice[self.index] as usize] {
	self.index += 1;
	}

We can use memchr2 to find " or \, then separately check the intervening characters for ch >= 0x20. I bet it would be faster than the current loop. This is a very similar pattern to what's discussed in https://nrk.neocities.org/articles/cpu-vs-common-sense.