Re: test_json_parser/002_inline is kind of slow

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Sep 27, 2025 at 12:43 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I tried it on my Mac M4 laptop, and saw the 002 test dropping from
>> 3592 ms to 540 ms, about an 85% savings. So I agree this is worth
>> doing. It's still unclear why Robert is seeing times so much worse
>> than mine, though.

> I don't have a clear explanation for that slowness either, but the
> patch cuts down the runtime by 89% on my machine.

Over the weekend I updated my macOS buildfarm animals to more recent
OS versions, and noticed this:

sifaka (Mac Mini M4 Pro), on macOS 15 (Sequoia) [1]

[06:50:39] t/001_test_json_parser_incremental.pl .. ok 868 ms ( 0.01 usr 0.00 sys + 0.33 cusr 0.48 csys = 0.82 CPU)
[06:50:44] t/002_inline.pl ........................ ok 5485 ms ( 0.06 usr 0.02 sys + 2.04 cusr 3.20 csys = 5.32 CPU)
[06:50:44] t/003_test_semantic.pl ................. ok 64 ms ( 0.00 usr 0.00 sys + 0.04 cusr 0.02 csys = 0.06 CPU)
[06:50:44] t/004_test_parser_perf.pl .............. ok 41 ms ( 0.00 usr 0.00 sys + 0.03 cusr 0.01 csys = 0.04 CPU)

sifaka (Mac Mini M4 Pro), on macOS 26 (Tahoe) [2]

[02:42:28] t/001_test_json_parser_incremental.pl .. ok 882 ms ( 0.01 usr 0.00 sys + 0.33 cusr 0.48 csys = 0.82 CPU)
[02:42:33] t/002_inline.pl ........................ ok 5573 ms ( 0.06 usr 0.02 sys + 2.06 cusr 3.18 csys = 5.32 CPU)
[02:42:34] t/003_test_semantic.pl ................. ok 66 ms ( 0.00 usr 0.00 sys + 0.04 cusr 0.02 csys = 0.06 CPU)
[02:42:34] t/004_test_parser_perf.pl .............. ok 42 ms ( 0.00 usr 0.00 sys + 0.03 cusr 0.01 csys = 0.04 CPU)

longfin (2018 Mac Mini, Intel-based), on macOS 13 (Ventura) [3]

[07:02:37] t/001_test_json_parser_incremental.pl .. ok 2355 ms ( 0.05 usr 0.01 sys + 1.21 cusr 1.05 csys = 2.32 CPU)
[07:02:52] t/002_inline.pl ........................ ok 14844 ms ( 0.29 usr 0.04 sys + 7.38 cusr 7.02 csys = 14.73 CPU)
[07:02:52] t/003_test_semantic.pl ................. ok 187 ms ( 0.00 usr 0.00 sys + 0.13 cusr 0.06 csys = 0.19 CPU)
[07:02:52] t/004_test_parser_perf.pl .............. ok 144 ms ( 0.01 usr 0.00 sys + 0.11 cusr 0.03 csys = 0.15 CPU)

longfin (2018 Mac Mini, Intel-based), on macOS 15 (Sequoia) [4]

[02:39:51] t/001_test_json_parser_incremental.pl .. ok 4005 ms ( 0.06 usr 0.00 sys + 1.86 cusr 1.92 csys = 3.84 CPU)
[02:40:16] t/002_inline.pl ........................ ok 25139 ms ( 0.33 usr 0.04 sys + 11.47 cusr 12.23 csys = 24.07 CPU)
[02:40:17] t/003_test_semantic.pl ................. ok 244 ms ( 0.00 usr 0.01 sys + 0.15 cusr 0.09 csys = 0.25 CPU)
[02:40:17] t/004_test_parser_perf.pl .............. ok 153 ms ( 0.00 usr 0.00 sys + 0.11 cusr 0.03 csys = 0.14 CPU)

longfin is intentionally an OS release behind sifaka, so these numbers
aren't directly comparable. However, the previous speed ratio of
about 2.75x is in line with the two machines' single-core performance
difference according to geekbench; the new ratio of 4.5x is not.

I conclude that Apple broke something about the speed of process
forking in the last OS release or two, but only on their Intel
machines. I doubt that they care a whole lot, given they're about
to stop supporting Intel hardware altogether :-(

Anyway, these numbers prompt me to wonder exactly which macOS
release Robert is running, and on what kind of hardware.

regards, tom lane

[1] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=sifaka&dt=2025-09-27%2010%3A42%3A05&stg=module-test_json_parser-check
[2] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=sifaka&dt=2025-09-29%2006%3A34%3A17&stg=module-test_json_parser-check
[3] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=longfin&dt=2025-09-27%2010%3A42%3A01&stg=module-test_json_parser-check
[4] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=longfin&dt=2025-09-29%2006%3A20%3A01&stg=module-test_json_parser-check