[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