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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Nov 25 18:09:08 PST 2008


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





------- Comment #4 from ggaren at apple.com  2008-11-25 18:09 PDT -------
> IMHO the performance benchmarks mostly show how fast the execution of bytecode.
> They almost say nothing about parsing and code generation, because most tests
> contain more or less loops, and its execution could cost more time than parsing
> them.

SunSpider is very careful to include the cost of lexing, parsing, and bytecode
generation in each iteration of a benchmark. When we look at Shark profiles of
SunSpider, we see lexing and parsing show up a bit, but it's a very small bit,
and easy to optimize.

Our general policy in JavaScriptCore and WebCore is not to bother caching data
that is very cheap to recompute. It seems unreasonable to risk going to disk to
retrieve data that you could otherwise compute in memory.

Perhaps there are other, better benchmarks that show parsing to be more
important. But I think it would be quite strange to write an application that
just loaded more and more code without ever executing it.

We also have an optimization to avoid creating an AST at all until a function
executes. So, in the case of an application that loads a lot of code without
executing any of it, JavaScriptCore will actually do quite well.

> Anyway, I will try to find some living example where this caching could work.

Did you end up finding something compelling?


-- 
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