4 ms·
Been a while, but I found it was best to assume all the text is ASCII, and fall back to a slower code path only if that turned out not to be the case. A lot o
by nitwit005 2y ago
Been a while, but I found it was best to assume all the text is ASCII, and fall back to a slower code path only if that turned out not to be the case.
A lot of tools that create JSON, XML, and so forth will escape any non ASCII characters by default. Python's json package, for example.
- torstenvl 2y agoAgreed. I saw measurable speed increases when defaulting to ASCII (via macro) and only actually calling the decoder function if the value wasn't < 128. #define cdpt(s) ((s[0] < 128) ? s[0] : cdpt_func(s)) https://github.com/torstenvl/trex/blob/master/src/trex.c https://github.com/torstenvl/trex/blob/master/src/trex.c
- dzaima 2y agoAn all-ASCII fast-path is basically obligatory for anything that cares about performance. And then the "slow path" gets a guarantee that there will be varying-length data, and, as you'll want it to not actually be slow, you'll still need to avoid branching on the now-guaranteed-variable width.