Bug 22227 – Caching AST and/or bytecode of JavaScripts

• Status: RESOLVED
• Resolution: WONTFIX
• Component: JavaScriptCore

[Gabor Loki]

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?

[Gabor Loki]

Created attachment 25121 [details]
export/import AST for caching

This patch adds export and import features for AST.

I don't expect a 'r+' for this patch. It is not a final code. The reason of why I ask for a review is that I would like to start a discussion about this caching method and its implementation possibilities.

The patch does not cause any JS regression, and does no performance regression on SunSpider and V8 tests.

[Geoffrey Garen]

Parsing doesn't show up very hot on most performance benchmarks. We're also exploring ways to avoid most of the overhead of parsing until a function executes. I'm skeptical of the advantages of caching parse trees.

[Gabor Loki]

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.

I'd appreciate if you can give me a clear view why you are skeptical.
Anyway, I will try to find some living example where this caching could work.

[Geoffrey Garen]

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

[Geoffrey Garen]

Comment on attachment 25121 [details]
export/import AST for caching

r- because we don't have an example in which this feature would be a performance advantage.

[Gabor Loki]

Created attachment 25624 [details]
result of AST caching on regression tests

Here is the first results of AST caching. It is measured during executing regression tests. This is not an online result, but it shows the advantage of caching.

[Gabor Loki]

Created attachment 25625 [details]
result of AST caching on cnn.com

Here is the first online result.
Only the 'Interpreter::evaluate' function was measured in this method.

[Gabor Loki]

Created attachment 25626 [details]
result of AST caching on kongregate.com

Here is another online result.
Only the 'Interpreter::evaluate' function was measured in this method.

[Gabor Loki]

All attached results contain three different measurements:
- 'Reference' (patched version of WebKit without CACHE_AST define)
   JS performance without AST cache.

- 'Build and use' (patched version of WebKit)
   After parsing each JS source export the AST into a file
   Next time for each JS source skip parsing, load and build AST from file.

- 'Only use' (patched version of WebKit)
   Load and build AST from file.

[Gabor Loki]

The summary of the attached results:

SunSpider: no significant effect (no progression/no regression)

Regression tests: 9% progression
1. Online example: 5 times faster
2. Online example: 3.5 times faster

[Gabor Loki]

The idea of caching AST is a little bit old. I won't be able to work on this in the near future. If you think this idea is still interesting, we can keep this feature request open. Otherwise it should be closed as won't fix.