Bug 259517

Summary: Consider parsing & analyzing JS in parallel for ES modules?
Product: WebKit Reporter: Jarred Sumner <jarred>
Component: JavaScriptCoreAssignee: 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   

Description Jarred Sumner 2023-07-25 20:34:00 PDT 
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
Comment 1 Radar WebKit Bug Importer 2023-07-26 20:46:25 PDT 
<rdar://problem/112952296>
Comment 2 Jarred Sumner 2023-07-26 20:52:09 PDT 
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