> For the complete documentation index, see [llms.txt](https://sliu583.gitbook.io/blog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sliu583.gitbook.io/blog/specific-work/seminar-and-talk/reading-groups/network-reading-group/ml-and-networking/other/horcrux-automatic-javascript-parallelism-for-resource-efficient-web-computation.md).

# Horcrux: Automatic JavaScript Parallelism for Resource-Efficient Web Computation

* Modern web browsing 
  * Performance matters
    * User: 53% of visits are abandoned if a mobile site takes longer than 3s to load 
    * Content Providers: if your site makes $100,000/day, 1s improvement in page load increases revenue by $7,000 daily 
* The problem: computation delays 
  * Evaluation setup: 
    * Performance metrics: Page Load Time (PLT), Speed Index (SI) 
  * Developed Region, Emerging Region 
* Why are computation delays significant 
  * 80% more JavaScript over the last 5 years 
  * Mobile Devices
    * **More cores != better performance** 
    * Reason: Single-thread execution --> solution: parallelizing JavaScript 
    * Main idea: **automatically parallelizes JavaScript execution using concolic execution to take advantage of phones multi-core CPUs** 
*  Parallelism Opportunities 
  * Web workers are widely supported by browsers 
  * Constrained APIs:
    * No access to DOM APIs 
    * No access to the main global state 
  * Legacy pages are highly amenable to safe parallelism 
* Challenges 
  * C1: ensuring correctness 
    * The exact state accessed by parallelized JavaScript --> conservative signatures 
      * Despite non-determinism and across all possible control paths 
    * Conservative signatures 
      * Dynamic analysis: track read / writes to page state 
      * Concolic execution: explore all possible control paths 
      * ![](/files/qu8gS4XUgNSCPdhoMuSo)
      * Server-side and offline 
  * C2: web workers constrained APIs
    * How to parallelize execution with constrained APIs? 
      * Client-side parallelization scheduler 
        * Runs in the main browser thread
        * Only task: manage offloads in event-driven mode 
  * C3: Offloading overheads 
    * Pass-by-value I/O can take \~0-10ms 
      * Root-function Granularity 
      * Offloading Granularity 
        * Trade-off: parallelization benefits vs. offloading overheads 
        * Solution: offloading root-function invocations 
        * 4x fewer offloads and 73% of parallelization benefits 
* Evaluation 
  * Impact on browser computation delays? 
    * Total computation time (TCT)
  * Impact on end-to-end performance?
    * Page Load Time (PLT), Speed Index (SI) 
  * Horcrux comparison to prior compute optimizations?
  * What do conservative signatures forgo?
  * How much are the server-side overheads?