oxc icon indicating copy to clipboard operation
oxc copied to clipboard

napi/parser: consider remove or reduce parse-raw.test.ts

Open Boshen opened this issue 8 months ago • 1 comments

napi/parser/test/parse-raw.test.ts takes too long, it is not suitable as unit tests.

Boshen avatar Apr 21 '25 04:04 Boshen

I have an idea how might be able to speed it up. At present we're comparing JSON AST with pretty-printed JSON, which are massive. If we compare compact-printed JSON, I'd hope that'd be faster.

But while we're working on TS-ESTree compat, it's not an ideal time to make this change. We're already struggling with subtle differences between Oxc's conformance tester and acorn-test262.

If it's OK, I'd like to leave this until after we've completed TS-ESTree alignment.

overlookmotel avatar Apr 24 '25 14:04 overlookmotel

I just discovered that while Vitest does run separate test files in separate processes, it runs all the it cases in a one file on a single thread.

We could massively speed up these tests if we were able to get cases to be run on multiple threads.

I've tried it.concurrent and describe.concurrent (docs), but they seem to be aiming to support async workloads. All cases still run on a single thread. This is of limited use to us, as the workload is CPU-bound.

overlookmotel avatar Jun 11 '25 12:06 overlookmotel

Based on the last sentence here: https://vitest.dev/guide/parallelism.html#test-parallelism

If you wish to run all tests concurrently, you can set the sequence.concurrent option to true.

This could be what you want: https://vitest.dev/config/#sequence-concurrent

GeoffreyParrier avatar Jun 11 '25 13:06 GeoffreyParrier

Thats what I thought initially too, but it seems not. It seems to be that old chestnut of the difference between "concurrent" and "parallel". sequence.concurrent option still runs all tests cases in a single thread. From the docs you pointed to:

Vitest doesn't perform any smart analysis and doesn't create additional workers to run these tests. This means that the performance of your tests will improve only if you rely heavily on asynchronous operations.

The slow tests in question are almost entirely CPU-bound (synchronous).

I've had to create a worker pool manually to get a speed-up (#11611).

overlookmotel avatar Jun 11 '25 14:06 overlookmotel

Fixed in #11611.

@Boshen If you think it's still not fast enough, please re-open. Using compact JSON (not pretty JSON) for test fixtures would also speed it up, but it's a bit tricky due to the TS multi-case files, so I'd prefer not to get into it now if possible.

overlookmotel avatar Jun 12 '25 15:06 overlookmotel