Re: test_json_parser/002_inline is kind of slow
| От | Andres Freund |
|---|---|
| Тема | Re: test_json_parser/002_inline is kind of slow |
| Дата | |
| Msg-id | v73qc4nxhjgzyx4aysii3aas37cc2zsy5gozcwlick3g2cx6o2@veh7ewp22vge обсуждение исходный текст |
| Ответ на | Re: test_json_parser/002_inline is kind of slow (Nathan Bossart <nathandbossart@gmail.com>) |
| Список | pgsql-hackers |
Hi,
On 2025-09-26 10:25:19 -0500, Nathan Bossart wrote:
> On Fri, Sep 26, 2025 at 11:11:52AM -0400, Robert Haas wrote:
> > I've noticed that when I run 'meson test', the test mentioned in the
> > subject line is usually the last one to finish. The test runs for 22
> > seconds on my machine, which is fairly high considering that 'meson
> > test' in total (and with MESON_TESTTHREADS=8) runs for 3 minutes and
> > 13 seconds. I think the reason for this relatively high runtime is
> > that it fires off a separate shell command for each separate test, and
> > there are 3400 of those. I'm not exactly sure what change to propose,
> > but I wonder if we could come up with a way of making this a bit more
> > efficient? Basically anything that would allow us to do multiple tests
> > without having to fork a new process for every single one seems like
> > it would probably save quite a bit.
>
> For some slow tests, we just have meson start it earlier with something
> like this:
>
> + 'test_kwargs': {'priority': 40},
>
> At least, that's enough to prevent it from completing last on my machine.
> But actually improving the efficiency of the test seems like a better
> long-term fix.
It never finishes last here (linux, 20 cores) - and the overall runtime isn't
that high, compared to the ones that finish last here [1] or are the slowest
ones [2]. I'm not saying we shouldn't work on the efficiency of the test -
forking thousands of times is pretty obviously absurdly inefficient - just
that re-prioritizing doesn't seem that promising.
Greetings,
Andres Freund
[1]
343/352 postgresql:test_json_parser / test_json_parser/002_inline OK
9.38s 3400 subtests passed
344/352 postgresql:ssl / ssl/001_ssltests OK
7.96s 247 subtests passed
345/352 postgresql:initdb / initdb/001_initdb OK
34.42s 57 subtests passed
346/352 postgresql:test_aio / test_aio/001_aio OK
11.71s 583 subtests passed
347/352 postgresql:pg_upgrade / pg_upgrade/006_transfer_modes OK
46.64s 60 subtests passed
348/352 postgresql:regress / regress/regress OK
57.33s 229 subtests passed
349/352 postgresql:pg_dump / pg_dump/002_pg_dump OK
45.00s 14236 subtests passed
350/352 postgresql:isolation / isolation/isolation OK
64.19s 122 subtests passed
351/352 postgresql:recovery / recovery/027_stream_regress OK
79.96s 11 subtests passed
352/352 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade OK
82.04s 19 subtests passed
[2]
262/352 postgresql:pg_amcheck / pg_amcheck/003_check OK
19.46s 75 subtests passed
326/352 postgresql:pgbench / pgbench/001_pgbench_with_server OK
19.54s 467 subtests passed
297/352 postgresql:pg_basebackup / pg_basebackup/010_pg_basebackup OK
24.56s 200 subtests passed
345/352 postgresql:initdb / initdb/001_initdb OK
34.42s 57 subtests passed
349/352 postgresql:pg_dump / pg_dump/002_pg_dump OK
45.00s 14236 subtests passed
347/352 postgresql:pg_upgrade / pg_upgrade/006_transfer_modes OK
46.64s 60 subtests passed
348/352 postgresql:regress / regress/regress OK
57.33s 229 subtests passed
350/352 postgresql:isolation / isolation/isolation OK
64.19s 122 subtests passed
351/352 postgresql:recovery / recovery/027_stream_regress OK
79.96s 11 subtests passed
352/352 postgresql:pg_upgrade / pg_upgrade/002_pg_upgrade OK
82.04s 19 subtests passed
В списке pgsql-hackers по дате отправления: