Faster streaming 'jsonl' parser

[asgerf]

Replaces the streaming JSONL parser with a faster one that doesn't call readline. The streaming JSONL parser on our branch was slower than the original sync version (but doesn't run out of memory), and it seems readline is a bottleneck:

Running the benchmark on a 21 MB logfile:

• readJsonlReferenceImpl: 172.4 ms (original non-streaming version)
• readJsonlFile: 283.3 ms (streaming version based on readline)
• readJsonlFile2: 151.3 ms (🚀 new version without readline)
• justReadline: 187.5 ms (consumes the file with readline and nothing else)

Note: targeting the hackathon branch. I think it's best to polish that up and try to merge it into main.

[esbena]

nice! I would expect the non-streaming version to be faster for small files like the one you benchmarked on, and would have advocated that as the default for small files.

For completeness, can you try on some larger files like https://github.com/codeql-dca-runners/codeql-dca-worker_javascript/actions/runs/11840886420/artifacts/2188663427 (amphtml on https://github.com/github/codeql-dca-main/issues/24803)

(you need to run codeql generate log-summary --format=predicates in.jsonl in.summary.jsonl to get the right format)

[esbena]

(on second thought, that will be a lot of work, so don't worry about it)

[asgerf]

I ran it anyway:

• readJsonlReferenceImpl: out of memory
• readJsonlFile: 6439.4 ms
• readJsonlFile2: 3538.4 ms
• justReadline: 3664.3 ms

[esbena]

Excellent. That is indeed convincing!

[aeisenberg]

Wow. This is great. Is this something you want to contribute to the main branch?

Also, do you have a hypothesis why readline is so slow?

[esbena]

My two guesses:

• readline reads smaller chunks than a plain readStream does by default
• readline has many string checking operations per chunk, the readStream implementation only cares for \n

[asgerf]

(@aeisenberg) Is this something you want to contribute to the main branch?

Yes the intent is to get this into main along with the 'Compare Performance' UI. But for benchmarking purposes it was easier to target the hackathon branch initially since that's where the previous streaming implementation lived.

[asgerf]

Although nobody formally 'Approved' the PR I'm gonna merge to the hackathon branch so I can start preparing the PR against main.