Bug 259517
| Summary: | Consider parsing & analyzing JS in parallel for ES modules? | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Jarred Sumner <jarred> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | john.david.dalton, mark.lam, webkit-bug-importer, ysuzuki |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Jarred Sumner
Since ESM has promises, code can be fetched and parsed in parallel. In theory, the lexing step could happen on another thread for top-level imports which are statically known. This can become tasks scheduled with JSC::DeferredWorkTimer. I imagine the linking step cannot be done in parallel, but the JSC::Lexer/JSC::Parser steps probably could be parallelized relatively efficiently? If this was already considered/obviously wouldn't work/would be very hard to do no worries but I wanted to draw attention to this potential performance optimization in the unlikely case it hadn't been considered before. The granularity I'm suggesting is per-module. I imagine it won't have a positive impact if there is only one module, but if there are multiple imports, in theory it could be good so long as those files all successfully evaluate
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/112952296>
Jarred Sumner
As one point of reference
In Bun, the time spent on Bun's transpiler and the time spent in the JSC lexer seem close.
Making the transpiler run concurrently speeds up "vite dev" start time by 20%. We keep it single-threaded for the very first file since the main thread would just be waiting anyway.
https://github.com/oven-sh/bun/assets/709451/9a047f39-2adb-4e77-baac-13c4ff000ef0
About 60ms is spent in JSC::Parser<JSC::Lexer<unsigned char>>::parseInner according to Instruments