JSON benchmark:#133832 (comment)

Benchmark hidden because not significant (11): encode 100 floats, encode ascii string len=100, encode Unicode string len=100, encode 1000 integers, encode 1000 floats, encode 1000 "ascii" strings, encode ascii string len=1000, encode escaped string len=896, encode 10000 integers, encode 10000 floats, encode 10000 "ascii" strings

Up to1.20x faster to encode booleans is interesting knowing that these strings are very short: "true" (4 characters) and "false" (5 characters).

ThePyUnicodeWriter_WriteASCII() function is faster thanPyUnicodeWriter_WriteUTF8(), but has an undefined behavior if the input string contains non-ASCII characters.

@serhiy-storchaka: What do you think of this function?

cc@ZeroIntensity

Well, we had_PyUnicodeWriter_WriteASCIIString for reasons.

Butunicode_decode_utf8_writer is already optimized for ASCII. Can it be optimized even more? In theory, it can be made almost as fast as_PyUnicodeWriter_WriteASCIIString.

We can add private_PyUnicodeWriter_WriteASCII for now, to avoid regression in JSON encode, and then try to squeeze nanoseconds fromPyUnicodeWriter_WriteUTF8. If we fail, we can add publicPyUnicodeWriter_WriteASCII.

But unicode_decode_utf8_writer is already optimized for ASCII. Can it be optimized even more?

I don't think that it can become as fast or faster than a function which takes ASCII string as argument. If we know that the input string is ASCII, there is no need to scan the string for non-ASCII characters, and we can take the fast path.

You're right that the UTF-8 decoder is already highly optimized.

In short:

• PyUnicodeWriter_WriteUTF8() callsascii_decode() which is an efficient ASCII decoder.
• PyUnicodeWriter_WriteASCII() callsmemcpy().

It's hard to beatmemcpy() performance!

Yes, although it was close, at least for moderately large strings. Could it be optimized even more? I don't know.

But decision aboutPyUnicodeWriter_WriteASCII should be made by the C API Workgroup. I'm not sure of my opinion yet. This API is unsafe.

I createdcapi-workgroup/decisions#65 issue.

Benchmark:

write_utf8 size=10: Mean +- std dev: 153 ns +- 1 nswrite_utf8 size=100: Mean +- std dev: 174 ns +- 1 nswrite_utf8 size=1,000: Mean +- std dev: 279 ns +- 0 nswrite_utf8 size=10,000: Mean +- std dev: 1.36 us +- 0.00 uswrite_ascii size=10: Mean +- std dev: 141 ns +- 0 nswrite_ascii size=100: Mean +- std dev: 149 ns +- 0 nswrite_ascii size=1,000: Mean +- std dev: 176 ns +- 3 nswrite_ascii size=10,000: Mean +- std dev: 690 ns +- 8 ns

On long strings (10,000 bytes), PyUnicodeWriter_WriteASCII() is up to 2x faster (1.36 us => 690 ns) than PyUnicodeWriter_WriteUTF8().

from_testcapiimportPyUnicodeWriterimportpyperfrange_100=range(100)defbench_write_utf8(text,size):writer=PyUnicodeWriter(0)for_inrange_100:writer.write_utf8(text,size)writer.write_utf8(text,size)writer.write_utf8(text,size)writer.write_utf8(text,size)writer.write_utf8(text,size)writer.write_utf8(text,size)writer.write_utf8(text,size)writer.write_utf8(text,size)writer.write_utf8(text,size)writer.write_utf8(text,size)defbench_write_ascii(text,size):writer=PyUnicodeWriter(0)for_inrange_100:writer.write_ascii(text,size)writer.write_ascii(text,size)writer.write_ascii(text,size)writer.write_ascii(text,size)writer.write_ascii(text,size)writer.write_ascii(text,size)writer.write_ascii(text,size)writer.write_ascii(text,size)writer.write_ascii(text,size)writer.write_ascii(text,size)runner=pyperf.Runner()sizes= (10,100,1_000,10_000)forsizeinsizes:text=b'x'*sizerunner.bench_func(f'write_utf8 size={size:,}',bench_write_utf8,text,size,inner_loops=1_000)forsizeinsizes:text=b'x'*sizerunner.bench_func(f'write_ascii size={size:,}',bench_write_ascii,text,size,inner_loops=1_000)

Do we know where the bottleneck is for long strings?
Would it make sense have a version offind_first_nonascii that checks and copies in the same loop?

Do we know where the bottleneck is for long strings?

WriteUTF8() has to check for non-ASCII characters: this check has a cost. That's the bottleneck.

Would it make sense have a version of find_first_nonascii that checks and copies in the same loop?

Maybe, I don't know if it would be faster.

Would it make sense have a version of find_first_nonascii that checks and copies in the same loop?

I tried but failed to modify the code to copy while reading (checking if the string is encoded to ASCII). The code is quite complicated.