What's the point? This just adds more maintenance if we make changes to how PyUnicodeWriter works.

They might have caused a performance regression compared to 3.13: faster-cpython/ideas#726
I'm still benchmarking, but wanted to already run the tests.

cc @vstinner, @mdboom

See also #133186.

If _PyUnicodeWriter_WriteASCIIString is significantly faster than PyUnicodeWriter_WriteUTF8, then we should expose it as a public API.

If _PyUnicodeWriter_WriteASCIIString is significantly faster than PyUnicodeWriter_WriteUTF8, then we should expose it as a public API.

I chose to not expose it since it generates an invalid string if the input string contains non-ASCII characters. But yeah, maybe we should expose it. The function only validates the input string in debug mode for best performance.

Would it be possible to only replace PyUnicodeWriter_WriteUTF8() with _PyUnicodeWriter_WriteASCIIString()? Do you get similar performance in this case?

Maybe, but my current benchmark has too much overhead to measure this accurately. I'll have to rewrite it first.

I hope we can figure out how to get the performance of the public API very close to the private one, such that everyone feels comfortable using it.

I updated the benchmark, but I don't understand why:

• writing integers is now 20% faster
• reading and writing unicode strings is now 2-5% slower (shouldn't be caused by noise)

Does this have something to do with the overallocate parameter?

Does this have something to do with the overallocate parameter?

The private API doesn't enable overallocation by default.

I replaced PyUnicodeWriter_WriteUTF8() with _PyUnicodeWriter_WriteASCIIString() in Modules/_json.c and ran a benchmark:

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

I built Python with ./configure && make and used CPU Isolation on Linux.

Benchmark code:

import json
import pyperf
runner = pyperf.Runner()

for count in (100, 1_000, 10_000):
    runner.bench_func(f'encode {count} booleans', json.dumps, [True, False] * (count // 2))
    runner.bench_func(f'encode {count} integers', json.dumps, list(range(count)))
    runner.bench_func(f'encode {count} floats', json.dumps, [1.0] * count)
    runner.bench_func(f'encode {count} "ascii" strings', json.dumps, ['ascii'] * count)

    text = 'ascii'
    text *= (count // len(text) or 1)
    runner.bench_func(f'encode ascii string len={len(text)}', json.dumps, text)

    text = ''.join(chr(ch) for ch in range(128))
    text *= (count // len(text) or 1)
    runner.bench_func(f'encode escaped string len={len(text)}', json.dumps, text)

    text = 'abcd€'
    text *= (count // len(text) or 1)
    runner.bench_func(f'encode Unicode string len={len(text)}', json.dumps, text)

I also ran my benchmark on this PR:

Benchmark hidden because not significant (1): encode Unicode string len=1000

The private API doesn't enable overallocation by default.

Yeah, but both the old code and the public API do, so it's not that. (And you really don't want to turn it off)

This line is inefficient for exact string instances (Py_INCREF is enough):

Here's the comparison with a minimal PR:

@vstinner, could you add a fast path for exact string instances in PyUnicodeWriter_WriteStr()? or can we merge this as is?

I created issue #133968 to track this work.

@vstinner, could you add a fast path for exact string instances in PyUnicodeWriter_WriteStr()?

I wrote #133969 to add a fast path.

I wrote #133969 to add a fast path.

Merged. I confirmed with two benchmarks that this small optimization makes a big difference on some use cases such as encoding short strings in JSON.

@ZeroIntensity:

If _PyUnicodeWriter_WriteASCIIString is significantly faster than PyUnicodeWriter_WriteUTF8, then we should expose it as a public API.

Ok, I created #133973 to add PyUnicodeWriter_WriteASCII().

Ok, I created #133973 to add PyUnicodeWriter_WriteASCII().

If that's merged we would use this aproach in 3.14, right?

@vstinner, it looks like the regression in json.loads() is caused by the heap allocation in PyUnicodeWriter_Create().
I've now delayed the allocation until it's necessary. Thoughts?

@vstinner, it looks like the regression in json.loads() is caused by the heap allocation in PyUnicodeWriter_Create().

Are you sure about that? The implementation uses a freelist which avoids the heap allocation in most cases.

I've now delayed the allocation until it's necessary. Thoughts?

Would you mind to create a separated PR just for that?

Are the benchmarks creating an unrealistic number of concurrent writers? That would starve the freelist and create some allocation overhead, but only on the benchmarks.

Are you sure about that? The implementation uses a freelist which avoids the heap allocation in most cases.

You're right, it does seem to be using the only entry of the freelist. (I disabled the malloc to check)
There might be some overhead compared to using the stack though.