[Webkit-unassigned] [Bug 22227] New: Caching AST and/or bytecode of JavaScripts

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Nov 13 02:19:32 PST 2008


https://bugs.webkit.org/show_bug.cgi?id=22227

           Summary: Caching AST and/or bytecode of JavaScripts
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Enhancement
          Priority: P3
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: loki at inf.u-szeged.hu


I was wondering why JSC does not provide a way to serialize a JavaScript. It
could be very handy in several cases, for example:
- large JS code, but only a small part of it will be executed
- with timeout or refresh rate WebCore does not need to touch the network for
external/included JS

Anyway, at least the AST caching could be profitable. I mean the parser does
know nothing about the source. It have to check tokens, do forward lookup,
handle syntax errors, etc. So the parser do many checks in contrast to a simple
binary reader. If we caching AST and writing into a well-defined binary form we
could save those parser's checks.

If we do one step forward and cache bytecode too we will save AST traversing
from code generation and reading/building this part of the AST from the binary
form.

The drawback of this method is the serialization, the caching.

I have implemented a simple AST exporting/importing feature for JSC. With it we
can measure how effective this kind of caching approach.

I would like to read your options about it. Is anyone interested in it? Is it a
good idea, or not? How could we make it a profitable feature?


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list