gh-118299: Re-use old indent in json.loads()

[nineteendo]

Benchmark

macOS

script

# speedup-json.dumps.sh
echo depth 1
              main/python.exe -m timeit -s "import json; data = []" "json.dumps(data, indent=1)"
speedup-json.dumps/python.exe -m timeit -s "import json; data = []" "json.dumps(data, indent=1)"
echo depth 10
              main/python.exe -m timeit -s "import json; nest = lambda depth: [] if depth < 1 else [nest(depth - 1)]; data = nest(10)" "json.dumps(data, indent=1)"
speedup-json.dumps/python.exe -m timeit -s "import json; nest = lambda depth: [] if depth < 1 else [nest(depth - 1)]; data = nest(10)" "json.dumps(data, indent=1)"
echo depth 100
              main/python.exe -m timeit -s "import json; nest = lambda depth: [] if depth < 1 else [nest(depth - 1)]; data = nest(100)" "json.dumps(data, indent=1)"
speedup-json.dumps/python.exe -m timeit -s "import json; nest = lambda depth: [] if depth < 1 else [nest(depth - 1)]; data = nest(100)" "json.dumps(data, indent=1)"

depth 1
50000 loops, best of 5: 4.49 usec per loop # before
50000 loops, best of 5: 4.53 usec per loop # after
# -> no difference
depth 10
20000 loops, best of 5: 19.2 usec per loop # before
20000 loops, best of 5: 17 usec per loop # after
# -> 1.13x faster
depth 100
1000 loops, best of 5: 318 usec per loop # before
1000 loops, best of 5: 291 usec per loop # after
# -> 1.09x faster

Windows

script

::speedup-json.dumps.bat
@echo off
echo depth 1
call               main\python -m timeit -s "import json; data = []" "json.dumps(data, indent=1)"
call speedup-json.dumps\python -m timeit -s "import json; data = []" "json.dumps(data, indent=1)"
echo depth 10
call               main\python -m timeit -s "import json; nest = lambda depth: [] if depth < 1 else [nest(depth - 1)]; data = nest(10)" "json.dumps(data, indent=1)"
call speedup-json.dumps\python -m timeit -s "import json; nest = lambda depth: [] if depth < 1 else [nest(depth - 1)]; data = nest(10)" "json.dumps(data, indent=1)"
echo depth 100
call               main\python -m timeit -s "import json; nest = lambda depth: [] if depth < 1 else [nest(depth - 1)]; data = nest(100)" "json.dumps(data, indent=1)"
call speedup-json.dumps\python -m timeit -s "import json; nest = lambda depth: [] if depth < 1 else [nest(depth - 1)]; data = nest(100)" "json.dumps(data, indent=1)"

depth 1
50000 loops, best of 5: 4.56 usec per loop # before
50000 loops, best of 5: 4.56 usec per loop # after
# -> no difference
depth 10
10000 loops, best of 5: 21 usec per loop # before
10000 loops, best of 5: 19 usec per loop # after
# -> 1.11x faster
depth 100
500 loops, best of 5: 398 usec per loop # before
1000 loops, best of 5: 372 usec per loop # after
# -> 1.07x faster

• Issue: Re-use old indent in json.loads() #118299

[ericvsmith]

This seems like too complex of a change, unless the performance impact justifies a more thorough code review. Have you measured the performance improvement?

And why rename the function parameter names? That's not making this easier to review. Renaming does not seem important. At best it should be a separate commit, although I doubt it's worth doing.

[nineteendo]

Have you measured the performance improvement?

Yes, see the description of the pull request. If there are other cases you would like me to benchmark, let me know.

And why rename the function parameter names?

We're no longer passing the indent level, we're passing the newline indent now. I can keep the names, but it'll make the code more confusing for future readers.

[serhiy-storchaka]

The difference is so small that it does not worth a NEWS entry. In most cases there is no visible difference.

I did not not expect significal difference, algorithmically it has the same complexity, and computing the indentation string has minor contribution in the total time. I proposed this approach for the C code because it may simplify it, and the saving in computing the indentation for the closing bracket may have larger impact. It is less important in Python.

I would wait with until we finish with C implementation. If it will end with this approach, it will be a small argument of using it in the Python implementation too.

[nineteendo]

Can we use it for the Python implementation now #118105 is merged?

[serhiy-storchaka]

#118105 has been merged, but the story does not end here. See #118636 which uses a different approach.

[nineteendo]

Do you mean we will also be able to use caching in Python with improved performance? Aren't strings always copied when passed around?

[serhiy-storchaka]

Do you mean we will also be able to use caching in Python with improved performance?

I have doubts. Even this PR is too complicated for such small gain (taking into account that normally the C implementation is used). More complex caching scheme increases the cost. On other hand, the complicated C code can be translated to simple Python code, and the benefit/ratio cost can be very good. We cannot say until we try.

Aren't strings always copied when passed around?

Objects are never copied when passed as arguments in Python. And strings are never copied, they are immutable.

[nineteendo]

Even this PR is too complicated for such small gain

OK, I'll close it then, or did I misunderstand you?